Wireless Connectivity & Mobile Apps: Protocols, Networks & APIs

TAKEAWAYS:

• Wireless tech matters: Mobile apps rely on cellular (Ncell), Wi-Fi (hotspots), Bluetooth (Khalti payments), and NFC (NTC smart cards)—each has trade-offs in range, speed, and power.
• Protocols define communication: HTTP/HTTPS (web), MQTT (IoT), and WebSockets (real-time) handle data differently; choose based on latency vs. battery life.
• APIs bridge apps and servers: REST (Daraz orders) vs. GraphQL (NEPSE stock data) affect performance and flexibility.
• Security is non-negotiable: Encryption (TLS), OAuth (login via Google), and tokenization (Khalti) protect user data.
• Offline-first design: Apps like Pathao use local caching + sync (Unit 7) to work when connectivity drops.
• Regulatory compliance: Nepal’s NTC rules and PCI-DSS (for eSewa) mandate secure wireless data handling.

Core Wireless Technologies for Mobile Apps

Mobile apps connect via four primary wireless methods, each with distinct use cases. Below is a comparison table and real-world examples.

classDiagram
    class WirelessTech {
        +range
        +speed
        +powerUsage
        +useCase
    }
    class Cellular {
        +2G/3G/4G/5G
        +Ncell, NTC towers
    }
    class WiFi {
        +802.11a/b/g/n/ac
        +Hotspots, home networks
    }
    class Bluetooth {
        +Classic/BLE
        +Khalti POS, earbuds
    }
    class NFC {
        +13.56 MHz
        +NTC smart cards, contactless payments
    }
    WirelessTech <|-- Cellular
    WirelessTech <|-- WiFi
    WirelessTech <|-- Bluetooth
    WirelessTech <|-- NFC

1. Cellular Networks: From 2G to 5G

How it works: Mobile apps use cellular networks (managed by Ncell, NTC) via SIM cards. Data travels through base stations (towers) using protocols like LTE (4G) or NR (5G). Each generation improves speed, latency, and efficiency:

• 2G/3G: SMS, basic internet (e.g., old Ncell USSD services).
• 4G/LTE: HD streaming, VoIP (e.g., Pathao driver tracking).
• 5G: Ultra-low latency (<1ms), critical for autonomous vehicles (not yet in Nepal but tested by NTC).

Worked Example: Pathao’s Driver Tracking Pathao uses 5G (where available) or 4G to send driver location every 2 seconds via HTTP/2. If the connection drops:

1. Data buffers in the app’s local cache (Unit 7: Synchronization).
2. Syncs when connectivity resumes.
3. 5G’s 1ms latency ensures real-time updates vs. 4G’s 30ms.

sequenceDiagram
    participant Driver as Pathao Driver (Phone)
    participant Tower as Ncell 5G Tower
    participant Server as Pathao Server
    Driver->>Tower: GPS (5G, 1ms latency)
    Tower->>Server: HTTP/2 POST {"lat":27.7172, "lon":85.3240}
    Server->>Tower: ACK + Ride Status
    Tower->>Driver: Update UI (real-time)

2. Wi-Fi: Localized High-Speed Connectivity

How it works: Wi-Fi (IEEE 802.11) uses radio waves (2.4GHz/5GHz) to connect devices to a router. Mobile apps leverage Wi-Fi for:

• Offloading data from cellular (saves battery).
• Local area services (e.g., Daraz delivery hubs use Wi-Fi for internal tracking).

Worked Example: eSewa Payment Confirmation When you pay via eSewa:

1. Your phone connects to home Wi-Fi (if available) or falls back to 4G.
2. eSewa sends a HTTPS POST to its server with payment details.
3. Server responds with a JSON confirmation (encrypted via TLS 1.3).
4. If Wi-Fi drops mid-transaction, the app retries over cellular.

flowchart TD
    A["User taps 'Pay'"] --> B["Wi-Fi/4G Check"]
    B -->|"Wi-Fi Available"| C["HTTPS POST to eSewa Server"]
    B -->|"No Wi-Fi"| D["Fallback to 4G"]
    C --> E["Server validates & responds"]
    D --> E
    E --> F["Show 'Payment Successful'"]

3. Bluetooth and NFC: Short-Range, Low-Power

Bluetooth (Classic/BLE)

• Classic Bluetooth: Audio (earbuds), file transfer (obsolete in apps).
• BLE (Bluetooth Low Energy): Used in Khalti POS machines and health apps (e.g., blood glucose monitors).
  • How it works: Device (POS) acts as a peripheral; phone as a central. Data exchanged in packets (128 bytes max).
  • Example: Scanning a Khalti QR code triggers a BLE handshake to authorize payment.

NFC (Near Field Communication)

• How it works: Uses inductive coupling (13.56 MHz) for tap-to-pay (max 10cm range).
• Nepal Use Cases:
  • NTC smart cards for bus tickets.
  • Daraz contactless checkout (pilot in Kathmandu).
• Security: Encrypted via MIFARE Classic or NFC Secure Element.

Worked Example: Khalti Payment via NFC

1. User taps Khalti app on NFC-enabled POS.
2. Phone sends NDEF message (payment request) to POS.
3. POS verifies with Khalti’s server via HTTPS.
4. If approved, POS sends ACK + receipt.

stateDiagram-v2
    [*] --> Tap
    Tap --> Check:NFC Available?
    Check -->|Yes| Send:NDEF Payment Request
    Send --> Verify:Khalti Server
    Verify -->|Approved| Show:Receipt
    Verify -->|Declined| Show:Error
    Check -->|No| Fallback:QR Code

Wireless Protocols: HTTP, MQTT, and WebSockets

Apps use different protocols based on real-time needs and battery life.

1. HTTP/HTTPS: The Backbone of Web Apps

• How it works: Client (app) sends a request (GET/POST), server responds.
• HTTPS: Encrypted via TLS (e.g., eSewa uses TLS 1.3).
• Worked Example: Daraz Order Status
  1. App sends GET /api/order/12345 to Daraz’s server.
  2. Server responds with:

     {
       "status": "shipped",
       "location": {"lat":27.7172, "lon":85.3240},
       "eta": "2024-05-20T14:30:00"
     }
     

  3. App updates UI and caches the data for offline use.

2. MQTT: Lightweight IoT Messaging

• How it works: Uses a broker (e.g., Mosquitto) to publish/subscribe to topics.
• Nepal Example: NTC smart meters send usage data every hour via MQTT to a cloud server.
  • Topic: ntc/meter/001/sensor
  • Payload:

    {"timestamp": "2024-05-15T10:00:00", "usage_kWh": 5.2}
    

• Advantages:
  • Low bandwidth (ideal for rural areas with weak 2G).
  • QoS levels (0–2) for reliability.

flowchart TD
    A["Smart Meter"] -->|"MQTT Publish"| B["Broker: Mosquitto"]
    C["App Server"] -->|"MQTT Subscribe"| B
    B -->|"Push Update"| C
    C -->|"Update Dashboard"| D["NTC Portal"]

3. WebSockets: Real-Time Updates

• How it works: Persistent full-duplex connection (vs. HTTP’s request-response).
• Nepal Example: Pathao live tracking updates every 2 seconds.
  • Handshake: Upgrade from HTTP to WebSocket.
  • Messages:

    {"type": "location", "driverId": "DRV123", "lat":27.7172, "lon":85.3240}
    

Worked Example: NEPSE Stock Alerts

1. User opens NEPSE app and subscribes to NEPSE:1 (Nepal Stock Exchange).
2. Server sends WebSocket message when price changes:

   {"symbol": "NEPSE:1", "price": 2100.50, "time": "10:05:23"}
   

3. App updates UI without polling.

sequenceDiagram
    participant App as NEPSE App
    participant Server as NEPSE Server
    App->>Server: WebSocket Handshake (HTTP Upgrade)
    Server-->>App: Connection Acknowledged
    loop Real-time Updates
        Server->>App: {"symbol": "NEPSE:1", "price": 2100.50}
        App->>App: Update UI
    end

Wireless Security: Encryption and Authentication

Mobile apps must secure wireless data to comply with Nepal’s NTC rules and PCI-DSS (for payments).

1. HTTPS/TLS: Encrypting Web Traffic

• How it works:
  1. Client (app) sends ClientHello with supported cipher suites.
  2. Server responds with certificate (signed by CA like Let’s Encrypt).
  3. Symmetric key exchange (e.g., ECDHE) establishes encrypted session.
• Nepal Example: eSewa uses TLS 1.3 + AES-256-GCM for transactions.

Worked Example: eSewa Payment Flow

1. App connects to https://api.esewa.com.
2. Server presents Let’s Encrypt certificate.
3. App verifies certificate and negotiates AES-256 encryption.
4. Payment data (e.g., {"amount": 500, "to": "9812345678"}) is encrypted and sent.

flowchart TD
    A["App: ClientHello"] --> B["Server: Certificate"]
    B --> C["App: Verify Cert"]
    C --> D["App: Key Exchange"]
    D --> E["Encrypted Session"]
    E --> F["POST Payment Data"]

2. OAuth 2.0: Secure Authentication

• How it works: Apps (e.g., Google Login) get access tokens without storing passwords.
• Nepal Example: Khalti lets users log in via Google/Facebook OAuth.
  • Flow:
    1. App redirects to https://accounts.google.com/o/oauth2/auth.
    2. User logs in; Google returns authorization code.
    3. App exchanges code for JWT token.
    4. Token used for API calls (valid for 1 hour).

sequenceDiagram
    participant App as Khalti App
    participant User as User
    participant Google as Google OAuth
    App->>User: Redirect to Google Login
    User->>Google: Enter Credentials
    Google-->>App: Authorization Code
    App->>Google: Exchange for JWT
    Google-->>App: JWT Token
    App->>App: Use Token for API Calls

Offline-First Design: Handling Poor Connectivity

Nepal’s rural areas often have weak 2G/3G. Apps like Pathao and eSewa use:

1. Local Caching: Store data (e.g., order history) in SQLite.
2. Queueing: Pending transactions (e.g., payments) stored in a local queue.
3. Sync on Reconnect: Use background services (Android’s WorkManager) to sync when online.

Worked Example: Pathao Order Sync

1. User places order offline; data saved in Room Database.
2. When connectivity returns:
   • App checks WorkManager queue.
   • Sends pending orders via HTTP POST.
   • Deletes synced orders from local DB.

stateDiagram-v2
    [*] --> Offline
    Offline --> Place:Order (Saved Locally)
    Place --> Online
    Online --> Sync:Pending Orders
    Sync -->|Success| Delete:Local Copy
    Sync -->|Fail| Retry:Later

Exam Tip

How this unit is tested (TU/PU/NEB):

1. Definitions & Comparisons (30%):

   • Differentiate HTTP vs. WebSockets (latency, use case).
   • Compare BLE vs. NFC (range, power, security).
   • Explain TLS handshake steps (ClientHello, certificate, key exchange).

2. Scenario-Based Questions (40%):

   • "Design a wireless flow for a Khalti payment using NFC and HTTPS."
   • "Why does Pathao use WebSockets instead of HTTP polling?"
   • "How would you secure a Daraz app against MITM attacks?"

3. Diagrams & Traces (20%):

   • Draw a MQTT publish-subscribe flow for NTC smart meters.
   • Trace an HTTPS connection setup (TLS handshake).
   • Show the state of a Bluetooth BLE connection during a Khalti payment.

4. Code Snippets (10%):

   • Write a WebSocket client in Android (Java/Kotlin) to fetch NEPSE stock updates.
   • Show a MQTT publish in Python for a smart agriculture sensor.

Common Mistakes to Avoid:

• Confusing HTTP polling with WebSockets (WebSockets keep a persistent connection).
• Forgetting TLS certificate verification in HTTPS (always check issuer and pinning).
• Ignoring offline-first design (apps must handle weak connectivity in Nepal).

Quick Revision Table:

Final Worked Example: Full App Flow (eSewa Payment)

1. User Action: Taps "Pay Rs. 500" to 9812345678.
2. Connectivity Check: Uses Wi-Fi (preferred) or 4G.
3. Security:
   • App verifies eSewa’s TLS certificate.
   • User enters PIN (never sent over network).
4. Payment Request:

   POST /api/payment HTTP/2
   Host: api.esewa.com
   Content-Type: application/json
   Authorization: Bearer <JWT>
   
   {
     "amount": 500,
     "to": "9812345678",
     "pin": "****" (hashed locally)
   }
   

5. Response:

   {
     "status": "success",
     "transactionId": "TXN789",
     "balance": 4500
   }
   

6. Offline Handling: If Wi-Fi drops, request is queued and retried on reconnect.

flowchart TD
    A["User Taps Pay"] --> B["Check Wi-Fi/4G"]
    B -->|"Wi-Fi"| C["HTTPS POST to eSewa"]
    B -->|"4G"| D["HTTPS POST to eSewa"]
    C --> E["Server Validates"]
    D --> E
    E -->|"Success"| F["Show Receipt"]
    E -->|"Fail"| G["Queue & Retry"]