655  Layered Models: Knowledge Checks

655.1 Learning Objectives

By the end of these knowledge checks, you will be able to:

  • Apply encapsulation concepts: Trace data flow through network layers with header addition/removal
  • Explain addressing: Distinguish MAC, IP, and port addressing at different layers
  • Apply ARP: Understand IP-to-MAC resolution for local network communication
  • Troubleshoot by layer: Use systematic layer-by-layer approach to diagnose network issues
  • Calculate subnets: Determine network addresses, broadcast addresses, and usable host ranges

655.2 Prerequisites

Required Chapters:

Estimated Time: 20 minutes

Purpose: These questions test deep understanding, not memorization. Each explanation reveals the reasoning behind correct answers.

Strategy:

  1. Read the scenario carefully
  2. Think through your answer before looking at options
  3. Select your choice
  4. Study the explanation even if correct

Scoring guidance:

  • 0-40%: Review the model comparison chapter
  • 40-70%: Good foundation, review explanations
  • 70-100%: Strong understanding, ready for advanced topics

655.3 Understanding Checks

Scenario: You’re designing a smart agriculture system where soil moisture sensors send readings to a cloud analytics platform. Each sensor transmits a 20-byte reading through Wi-Fi. When you analyze the network traffic, you discover each transmission actually sends 62 bytes (20-byte payload + 8-byte UDP + 20-byte IP + 14-byte Ethernet).

Think about:

  1. Why does a 20-byte sensor reading require 62 bytes on the network?
  2. Which layer adds routing information to help data find its way from farm to cloud?

Key Insight: The Network Layer (Layer 3) adds the 20-byte IP header containing source and destination addresses, enabling routers to forward your sensor data across the internet. Without this addressing, your data would be trapped on the local network. UDP (Transport Layer 4) adds reliability options, Ethernet (Data Link Layer 2) adds local delivery addressing, and the Physical Layer converts everything to radio signals.

Verify Your Understanding:

  • If you deploy 100 sensors transmitting every minute, how much of your cellular bandwidth is consumed by protocol overhead? (Answer: 42 bytes overhead / 62 total = 68% overhead! This explains why edge processing and data aggregation save significant bandwidth costs.)

Scenario: Your smart factory uses Zigbee sensors on the factory floor communicating with a gateway that forwards data to the cloud via Ethernet. A sensor sends a temperature reading that arrives at the gateway via Zigbee radio, and the gateway must forward it to the cloud server.

Think about:

  1. What happens to the packet headers as it transitions from Zigbee to Ethernet?
  2. Which OSI layers remain unchanged through this translation?

Key Insight: The gateway operates at Layers 1-3, performing protocol translation. It strips the Zigbee Physical (L1) and MAC (L2) headers, extracts the IP packet (L3+), then wraps it in new Ethernet L2 and Physical L1 headers. Critically, the IP addressing (L3), TCP/UDP ports (L4), and application payload (L7) remain completely unchanged. This is why IP-based IoT protocols work so well - they provide end-to-end addressing independent of the underlying wireless technology.

Verify Your Understanding:

  • Why can your sensor reading traverse Zigbee to Ethernet to Wi-Fi to Cellular networks seamlessly? (Answer: Because Layer 3 IP addressing is preserved throughout, while only Layers 1-2 change at each hop.)

Scenario: You’re deploying battery-powered environmental sensors in a remote forest using IEEE 802.15.4 radios (127-byte maximum frame size). Each sensor reading is only 4 bytes, but after adding UDP (8 bytes), IP (20 bytes), and 802.15.4 headers (25 bytes), you’re transmitting 57 bytes per reading.

Think about:

  1. Why is 93% of your transmission just overhead (53 bytes overhead / 57 total)?
  2. How can you extend battery life given that radio transmission dominates power consumption?

Key Insight: For tiny IoT payloads, protocol overhead is massive. Solutions: (1) Payload aggregation - buffer 10 readings locally (40 bytes payload) and send one packet. Overhead drops to 53/93 = 57% instead of 93%. (2) Header compression - 6LoWPAN compresses IPv6 headers from 40 bytes to ~6 bytes using context. (3) Application optimization - use CoAP (binary) instead of HTTP (text) for the application protocol.

Verify Your Understanding:

  • If your sensor transmits once per minute at SF10 (247ms airtime), what percentage of time is the radio active? How much longer would the battery last if you aggregate 10 readings? (Answer: Currently 0.04% duty cycle. With 10x aggregation, same data delivered with 10x fewer transmissions = ~10x battery life extension from 1 year to 10 years!)

655.4 Multiple Choice Questions

Question 1: An IoT gateway receives a packet from a Zigbee sensor and must forward it to a cloud server via Ethernet. What transformation occurs, and which OSI layers are involved?

Explanation: The gateway performs Layer 2 (Data Link) switching/routing: (1) Receive: Zigbee packet arrives with IEEE 802.15.4 PHY/MAC headers (Layers 1-2). (2) Strip: Remove Zigbee L1/L2 headers, extract IP packet (Layer 3+). (3) Add: Wrap IP packet in Ethernet L2 header (new MAC addresses) and transmit via Ethernet PHY (new L1). (4) Preserve: IP header (L3), UDP/TCP (L4), and payload (L5-L7) remain completely unchanged. This is called bridging/routing. The gateway operates at Layers 1-3, translating between different physical/data-link technologies while preserving end-to-end addressing. Key insight: IP addressing (L3) provides network-independent communication - packets can traverse Zigbee to Ethernet to Wi-Fi to Cellular seamlessly!

Question 2: In the TCP/IP model, which layer combines OSI’s Session, Presentation, and Application layers (L5-L7)?

Explanation: The TCP/IP model is simpler (4 layers) vs OSI (7 layers): TCP/IP Application Layer = OSI L5 Session + L6 Presentation + L7 Application. Examples: HTTP (web), MQTT (IoT messaging), DNS (name resolution), FTP (file transfer). These protocols handle application-level semantics, data formatting, and session management. TCP/IP Transport = OSI L4 (TCP/UDP). TCP/IP Internet = OSI L3 (IP routing). TCP/IP Network Access = OSI L1+L2 (Ethernet, Wi-Fi physical/data link). Why simpler? TCP/IP model reflects real-world implementations - most applications don’t strictly separate session/presentation/application functions. OSI is more theoretical/comprehensive. IoT protocols like CoAP and MQTT are Application Layer (TCP/IP) protocols.

Question 3: A smart home hub has MAC address 00:1A:2B:3C:4D:5E and IP address 192.168.1.100. A laptop at 192.168.1.50 (MAC: AA:BB:CC:DD:EE:FF) needs to send data to the hub. Which address is used at Layer 2, and which at Layer 3?

Explanation: Layer 2 (Data Link) uses MAC addresses (48-bit hardware addresses) for local network delivery. Ethernet frame header contains: Source MAC (AA:BB:CC:DD:EE:FF) to Destination MAC (00:1A:2B:3C:4D:5E). Layer 3 (Network) uses IP addresses (32-bit IPv4 or 128-bit IPv6 logical addresses) for routing across networks. IP header contains: Source IP (192.168.1.50) to Destination IP (192.168.1.100). Both headers coexist! Frame structure: [Ethernet Header: MAC to MAC] [IP Header: IP to IP] [UDP/TCP Header] [Data]. The laptop uses ARP (Address Resolution Protocol) to discover the hub’s MAC address from its IP address: “Who has 192.168.1.100?” then Hub replies “I am 00:1A:2B:3C:4D:5E”. Then it sends the frame using both addresses.

Question 4: Why does IPv4 use 32-bit addresses (4.3 billion possible) while MAC addresses use 48 bits (281 trillion possible), yet we’re running out of IPv4 but not MAC addresses?

Explanation: The exhaustion paradox: IPv4 addresses (32-bit, 4.3B) require hierarchical allocation for routing - ISPs get blocks, assign to customers, routers maintain tables. Can’t randomly assign! Many addresses reserved (10.0.0.0/8, 192.168.0.0/16, multicast). Fragmented allocation wastes space. Result: Effective exhaustion by 2011. MAC addresses (48-bit, 281T) work on local networks only - not globally routed! Your device’s MAC (e.g., AA:BB:CC:DD:EE:FF) only matters on your local LAN. Different LANs can (and do) have duplicate MACs without issues. IEEE allocates OUI prefixes (first 24 bits) to vendors who assign the rest. No routing tables needed. Solution: IPv6 (128-bit, 340 undecillion addresses) provides hierarchical routing with effectively unlimited addresses. MAC addresses remain 48-bit - no need to change since they’re local-only.

Question 5: An IoT sensor sends temperature data via UDP (8-byte header) over IPv4 (20-byte header) through Ethernet (18-byte header + 4-byte trailer). If the sensor reading is 4 bytes, what percentage is overhead?

Explanation: Calculation: Payload: 4 bytes (temperature reading). Overhead: UDP (8) + IPv4 (20) + Ethernet header (14) + Ethernet trailer (4) = 46 bytes. Wait, let me recalculate: Standard Ethernet header is 14 bytes, preamble (8) + trailer (4) = 22 bytes. So overhead = 8 (UDP) + 20 (IPv4) + 14 (Eth header) = 42 bytes minimum. If counting full frame overhead (preamble + trailer): 42 + 8 + 4 = 54 bytes. Overhead ratio = 54/4 = 1350% or 54/(54+4) = 93% overhead! This is why header compression matters for IoT! Solutions: (1) Payload aggregation: Send 100 readings (400 bytes) per packet - overhead drops to 54/400 = 12%. (2) Header compression: 6LoWPAN compresses 20-byte IPv4 to ~3 bytes. (3) Application protocol optimization: Use CoAP (binary) not HTTP (text). For constrained IoT devices, minimizing overhead is critical for battery life and bandwidth.

Question 6: In the 7-Level IoT Reference Model, which layers are typically implemented on constrained IoT devices vs cloud servers?

Explanation: The 7-Level IoT Model splits responsibilities: On Device (constrained): L1 Physical: Sensors/actuators (temperature, motion). L2 Connectivity: Network layer (Wi-Fi, Zigbee, LoRa). L3 Edge Computing: Local processing (filtering, aggregation). L4 Data Accumulation: Store and forward (buffer data). On Cloud (powerful): L5 Data Abstraction: Databases, data lakes. L6 Application: Business logic, dashboards, ML models. L7 Collaboration: User interfaces, APIs, integrations. Why this split? (1) Resource constraints: Device has limited CPU/memory/power - can’t run heavy analytics. (2) Scalability: Cloud handles millions of devices. (3) Flexibility: Update business logic without reflashing devices. Edge computing trend: More L5-L6 moving to edge gateways (fog computing) for real-time response and reduced latency. Smart home hubs run local automation (L6) without cloud dependency.

Question 7: A network troubleshooter uses ping 192.168.1.1 successfully but curl http://example.com fails. Which OSI layers are working and which are failing?

Explanation: Ping success to 192.168.1.1 proves: L1 (Physical): Cable/radio working - bits transmitting. L2 (Data Link): Ethernet/Wi-Fi frames reaching destination MAC. L3 (Network): IP routing functional - ICMP Echo Request/Reply. curl failure to http://example.com indicates: DNS failure (L7): Can’t resolve “example.com” to IP address. Try curl http://93.184.216.34 (example.com’s IP) to test. If this works - DNS problem. If still fails - L4-L7 issue: TCP connection (L4), TLS/SSL (L6), HTTP (L7), or firewall blocking outbound port 80/443. Troubleshooting steps: (1) ping 8.8.8.8 (Google DNS) - tests L3 to internet. (2) nslookup example.com - tests DNS resolution (L7). (3) telnet example.com 80 - tests TCP connection (L4). (4) curl -v http://example.com - verbose L7 diagnostics. This layered approach isolates exactly which layer fails!

Question 8: Why does ARP (Address Resolution Protocol) use broadcast at Layer 2 rather than unicast?

Explanation: ARP solves the chicken-and-egg problem: Scenario: Laptop (192.168.1.50) wants to send data to printer (192.168.1.100). It knows the destination IP address (L3) but needs the MAC address (L2) to build the Ethernet frame. ARP Request (broadcast): “Who has 192.168.1.100? Tell 192.168.1.50 (MAC: AA:BB:CC:DD:EE:FF).” Sent to broadcast MAC address FF:FF:FF:FF:FF:FF - every device on LAN receives it. Why broadcast? Because we don’t know the target’s MAC yet! Can’t unicast to an unknown address. ARP Reply (unicast): Printer responds directly to laptop: “192.168.1.100 is at 00:11:22:33:44:55.” Now laptop caches this mapping in its ARP table (120 seconds default TTL). Future packets to 192.168.1.100 skip ARP - use cached MAC. Efficiency: ARP overhead is minimal - one broadcast per new destination, cached for minutes. Alternative (gratuitous ARP): Devices announce their own IP to MAC proactively to update neighbor caches.

Question 9: An IPv4 address 192.168.10.50/24 is assigned to a sensor. What is the network address, broadcast address, and number of usable host addresses?

Explanation: The /24 notation means the first 24 bits are the network portion, last 8 bits are host portion. Network address: Set all host bits to 0 - 192.168.10.0 (identifies the subnet). Broadcast address: Set all host bits to 1 - 192.168.10.255 (reaches all devices on subnet). Usable host addresses: 2^8 = 256 addresses, minus 2 reserved (network + broadcast) = 254 usable. Range: 192.168.10.1 through 192.168.10.254. Subnet mask: /24 = 255.255.255.0. Key insight: The sensor at 192.168.10.50 can communicate directly (L2 Ethernet) with any device in 192.168.10.1-254 (same subnet). Packets to other subnets (e.g., 192.168.11.x) must go through a router (gateway, typically .1 or .254). This is why default gateway configuration matters! IPv6 equivalent: 2001:db8::/64 has 2^64 = 18 quintillion usable addresses per subnet!

Question 10: The shopping trip analogy states “forgot wallet = can’t complete purchase.” Which real network scenario does this represent?

Explanation: The analogy illustrates layer interdependence - each layer provides services to the layer above. “Forgot wallet” = missing required component at one layer. Example scenarios: (1) Layer 4 failure: Application tries to send HTTP request, but TCP port 80 is blocked by firewall - data prepared at L7 but can’t be delivered at L4. Like having shopping list but no wallet. (2) Layer 3 failure: Ethernet working (L1-L2) but no IP address assigned (L3) - frames transmit locally but can’t route to internet. Like arriving at mall but forgetting wallet in car. (3) Layer 2 failure: IP address configured (L3) but Wi-Fi password wrong (L2 authentication) - can’t join network. Like having wallet but locked out of store. Key principle: Network communication requires success at ALL layers. One failure anywhere breaks the chain. Troubleshooting: Work bottom-up (L1 to L7) or top-down (L7 to L1) to isolate which layer fails. Tools: Physical inspection (L1), ifconfig/ipconfig (L2-L3), ping (L3), telnet (L4), curl (L7).

Question 11: Why do IoT reference models (7-Level IoT, ITU-T Y.2060) add layers beyond the OSI 7-layer model?

Explanation: OSI model (1984) was designed for point-to-point computer networking - getting data from A to B. IoT requirements are broader: (1) Massive scale: Billions of devices, not thousands. (2) Heterogeneity: Tiny sensors to powerful gateways. (3) Edge intelligence: Local processing/filtering. (4) Data pipeline: Sensor to storage to analytics to business action. (5) Management: Remote provisioning, updates, monitoring. 7-Level IoT Model layers: L1-L2: Same as OSI (Physical/Connectivity). L3 Edge Computing: Local processing (aggregate 1000 readings to 1 average). New layer! L4 Data Accumulation: Store and forward, buffering. L5 Data Abstraction: Databases (time-series). L6 Application: Analytics, ML, dashboards. L7 Collaboration: Business processes, APIs. ITU-T Y.2060 similarly extends with Management and Security as crosscutting layers. Why? IoT is more than networking - it’s a complete system from sensor to business value. Traditional OSI stops at “data delivered”; IoT models continue through “data analyzed and action taken.”

655.5 Multi-Select Questions

Question 12: Drag protocols and services to the correct OSI layer they primarily operate at. Which of the following assignments are correct? (Select ALL that apply)

Explanation: Correctly categorizing protocols by OSI layer is fundamental to network troubleshooting: (A) Physical Layer (L1) is correct - this layer handles the physical transmission medium: electrical signals on copper cables, light pulses in fiber optics, radio frequencies in Wi-Fi (2.4/5 GHz), and physical connectors (RJ45, USB). (C) Network Layer (L3) is correct - IP (Internet Protocol) provides logical addressing and routing between networks. Routers operate at L3, making forwarding decisions based on IP addresses. ICMP (ping) also operates here for diagnostics. (D) Data Link Layer (L2) is correct - handles local network delivery using MAC addresses (48-bit hardware addresses). Ethernet frames, Wi-Fi 802.11 MAC layer, and network switches all operate at L2. (E) Application Layer (L7) is correct - these protocols provide end-user services: HTTP (web), MQTT/CoAP (IoT messaging), DNS (name resolution), SMTP (email). (B) Transport Layer is INCORRECT - HTTP, FTP, and DNS are Application Layer (L7) protocols. The Transport Layer (L4) contains TCP and UDP, which provide port-based multiplexing and optional reliability. The confusion arises because these L7 protocols run “over” TCP/UDP, but they themselves are L7.

Question 13: Which of the following statements correctly describe responsibilities of the Network Layer (Layer 3) in the OSI model? (Select ALL that apply)

Explanation: The Network Layer (L3) has specific responsibilities distinct from other layers: (B) Logical addressing is correct - L3 uses IP addresses to identify devices across networks. IPv4 uses 32-bit addresses (e.g., 192.168.1.1), IPv6 uses 128-bit addresses (e.g., 2001:db8::1). These are logical addresses assigned by network administrators, unlike physical MAC addresses. (D) Routing is correct - L3’s primary function is determining the path packets take across interconnected networks. Routers maintain routing tables with next-hop information, using protocols like OSPF, BGP, or static routes. (E) Fragmentation is correct - when an IP packet exceeds the link’s MTU (e.g., 1500 bytes for Ethernet, 127 bytes for IEEE 802.15.4), L3 fragments it into smaller pieces, each with its own IP header. The destination reassembles fragments. (A) Reliable delivery is INCORRECT - this is the Transport Layer’s (L4) responsibility. IP at L3 provides “best-effort” delivery with no guarantees. TCP at L4 adds reliability with ACKs and retransmissions. (C) MAC addresses is INCORRECT - this is Data Link Layer (L2) responsibility. L3 uses IP addresses; L2 uses MAC addresses.

655.6 Matching Questions

Question 14: Match OSI layers to their corresponding TCP/IP model layers:

OSI Layers:

  • L7: Application
  • L6: Presentation
  • L5: Session
  • L4: Transport
  • L3: Network
  • L2: Data Link
  • L1: Physical

TCP/IP Layers:

  • Application Layer
  • Transport Layer
  • Internet Layer
  • Network Access Layer

Which mapping is correct?

Explanation: The TCP/IP model (4 layers) is a simplified version of the OSI model (7 layers): TCP/IP Application Layer combines OSI’s Application (L7), Presentation (L6), and Session (L5). In practice, most applications like HTTP, MQTT, CoAP handle all three functions without strict separation. For example, HTTP manages sessions (cookies), presents data (Content-Type headers), and provides application semantics (GET/POST methods). TCP/IP Transport Layer maps directly to OSI Layer 4 (Transport), providing TCP and UDP for end-to-end communication with port multiplexing. TCP/IP Internet Layer maps to OSI Layer 3 (Network), providing IP routing and addressing. This layer handles logical addressing and packet forwarding across networks. TCP/IP Network Access Layer combines OSI’s Data Link (L2) and Physical (L1). It handles both the physical transmission medium (cables, radio) and local network framing (Ethernet, Wi-Fi MAC). The TCP/IP model reflects real-world implementation where strict OSI layer separation isn’t always practical. Option A incorrectly creates separate Presentation/Session layers in TCP/IP. Option C incorrectly combines L3+L2 into Internet. Option D suggests one-to-one mapping which doesn’t exist.

Question 15: Rank the following steps in the correct order of data encapsulation as a sensor sends temperature data through the network stack (from application creation to physical transmission):

A. Application creates 4-byte temperature payload B. Transport layer (UDP) adds 8-byte header with port numbers C. Network layer (IP) adds 20-byte header with source/destination IP addresses D. Data Link layer (Ethernet) adds 14-byte header with MAC addresses and 4-byte trailer E. Physical layer converts frame to electrical/radio signals and transmits

Which ordering is correct?

Explanation: Data encapsulation follows strict top-down order during transmission: Step 1 (A): Application Layer creates the data to send - in this case, a 4-byte temperature reading (e.g., 72.5F encoded as a float or integer). Step 2 (B): Transport Layer adds UDP header (8 bytes) containing source port (e.g., 5683 for CoAP), destination port, length, and checksum. Payload is now 4+8=12 bytes. Step 3 (C): Network Layer adds IP header (20 bytes IPv4 or 40 bytes IPv6) containing source IP address, destination IP address, TTL, protocol type (17 for UDP), and checksum. Packet is now 12+20=32 bytes. Step 4 (D): Data Link Layer adds Ethernet frame header (14 bytes: dest MAC, source MAC, EtherType) and trailer (4-byte CRC checksum). Frame is now 32+14+4=50 bytes. Step 5 (E): Physical Layer converts the 50-byte frame into electrical signals (Ethernet), radio waves (Wi-Fi), or light pulses (fiber optic) and transmits bit-by-bit. The receiver performs the reverse process (decapsulation): Physical to Data Link to Network to Transport to Application, stripping headers at each layer. Option B shows receiver order (incorrect for transmission), Options C and D skip or reorder layers incorrectly.

655.7 Design Challenge

Question 16: A smart building deploys 500 IoT sensors across 5 floors. The network architect must design the IP addressing scheme. Given these requirements and constraints, which design is optimal?

Requirements:

  • Support 100 sensors per floor with room for 50% growth (150 per floor)
  • Enable routing between floors
  • Minimize IP address waste
  • Simplify troubleshooting (human-readable addressing)

Available network: 10.20.0.0/16

Design Options:

A. Single flat network: 10.20.0.0/23 (512 addresses for all 500 sensors) B. One subnet per floor: 10.20.1.0/24, 10.20.2.0/24, 10.20.3.0/24, 10.20.4.0/24, 10.20.5.0/24 C. Optimized subnets per floor: 10.20.1.0/25 (126 usable hosts per floor) D. Tiny subnets: 10.20.1.0/27, 10.20.1.32/27, etc. (30 hosts each)

Which design best meets all requirements?

Explanation: Optimal subnet design balances growth, efficiency, and manageability: Option C (/25 subnets) is best: Each /25 subnet provides 2^7 = 128 addresses - 2 (network + broadcast) = 126 usable host addresses. This meets the 150-device requirement (100 current + 50% growth) with minimal waste. The addressing scheme is human-readable: Floor 1 = 10.20.1.0/25 (10.20.1.1-126), Floor 2 = 10.20.2.0/25 (10.20.2.1-126), etc. Routers can summarize routes, and troubleshooting is intuitive (10.20.3.x means Floor 3). Why NOT Option A: A single /23 (512 addresses) creates a flat network requiring all 500 sensors to be in the same broadcast domain. This causes excessive ARP traffic and prevents routing optimization between floors. Also, 10.20.0.x and 10.20.1.x addresses don’t clearly indicate floor location. Why NOT Option B: /24 subnets provide 254 hosts - excessive for 150-device requirement, wasting 104 addresses per floor (520 total wasted). While easy to remember, it’s inefficient use of address space. Why NOT Option D: /27 subnets provide only 30 usable hosts - insufficient for 150 devices. Would need 5 subnets per floor (150 divided by 30), creating management complexity with addresses like 10.20.1.0/27, 10.20.1.32/27, 10.20.1.64/27, etc. Best practice: Right-size subnets to meet growth requirements with 10-20% headroom, use hierarchical addressing for clarity.

655.8 Summary

These knowledge checks tested your understanding of:

  • Layer-by-layer troubleshooting: Using ping, curl, and other tools to isolate failures
  • Encapsulation overhead: Why tiny IoT payloads have massive protocol overhead (93%+)
  • MAC vs IP addressing: Layer 2 local delivery vs Layer 3 global routing
  • ARP operation: Broadcast requests and unicast replies for IP-to-MAC mapping
  • Subnet calculations: Network address, broadcast, and usable host ranges
  • OSI/TCP-IP mapping: How 7 layers compress to 4 layers
  • IoT reference models: Why IoT needs layers beyond traditional networking

655.9 What’s Next

Continue your learning with resources and visual references:

Or apply your knowledge: