Skip to content
← Network Survey User Manual

gRPC Streaming

gRPC (gRPC Remote Procedure Call) is a high-performance, open-source RPC framework that uses HTTP/2 and Protocol Buffers. Network Survey supports gRPC for efficient, low-latency data streaming.

Connection Setup

Section titled “Connection Setup”

Manual Configuration

Section titled “Manual Configuration”
  1. Menu → gRPC Connection
  2. Enter connection details:
    • Host: grpc.example.com
    • Port: 2621 (or custom)
    • TLS Enabled: Toggle on for encrypted
  3. Toggle technologies to stream
  4. Tap “Connect”

Message Types

Section titled “Message Types”

See Message Formats and Network Survey Messaging docs for complete specifications.

Setting Up a gRPC Server

Section titled “Setting Up a gRPC Server”

An example gRPC server implementation is available on GitHub:

🔗 NS Messaging Go gRPC Server

Section titled “🔗 NS Messaging Go gRPC Server”

This repository includes:

  • Example Go server implementation for receiving Network Survey data
  • Example handlers for all message types (Cellular, Wi-Fi, Bluetooth, GNSS)

For complete protobuf definitions and message specifications, see Network Survey Messaging Documentation.

Message Format

Section titled “Message Format”

gRPC uses binary Protocol Buffers, not JSON. Messages are defined in .proto files.

Example LTE Message (protobuf):

message LteRecord {
   string version = 1;
   string messageType = 2;
   LteRecordData data = 3;
}


message LteRecordData {
   string deviceSerialNumber = 1;
   string deviceName = 2;
   string deviceTime = 3;
   double latitude = 4;
   double longitude = 5;
   float altitude = 6;
   string missionId = 7;
   int32 recordNumber = 8;
   int32 groupNumber = 9;
   int32 accuracy = 10;
   uint32 locationAge = 11;
   float speed = 55;


   float heading = 50;
   float pitch = 51;
   float roll = 52;
   float fieldOfView = 53;
   float receiverSensitivity = 54;


   google.protobuf.Int32Value mcc = 16;
   google.protobuf.Int32Value mnc = 17;
   google.protobuf.Int32Value tac = 18;
   google.protobuf.Int32Value eci = 19;
   google.protobuf.Int32Value earfcn = 20;
   google.protobuf.Int32Value pci = 21;
   google.protobuf.FloatValue rsrp = 22;
   google.protobuf.FloatValue rsrq = 23;
   google.protobuf.Int32Value ta = 24;
   google.protobuf.BoolValue servingCell = 25;
   com.craxiom.messaging.ltebandwidth.LteBandwidth lteBandwidth = 26;
   string provider = 27;
   google.protobuf.FloatValue signalStrength = 28;
   google.protobuf.Int32Value cqi = 29;
   google.protobuf.Int32Value slot = 30;
   google.protobuf.FloatValue snr = 31;
}

On the wire: Binary encoded (much smaller than JSON)

Advantages

Section titled “Advantages”

Efficiency:

  • Binary format = smaller messages
  • ~50-70% smaller than JSON
  • Lower bandwidth requirements

Performance:

  • HTTP/2 multiplexing
  • Header compression
  • Lower latency

Type Safety:

  • Strongly typed messages
  • Compile-time verification
  • Auto-generated client/server code

Backward Compatibility:

  • Protocol Buffers support versioning
  • Add new fields without breaking clients

Disadvantages

Section titled “Disadvantages”

Complexity:

  • More setup than MQTT
  • Requires protobuf compilation
  • Steeper learning curve

Tooling:

  • No ready-made tools
  • Less common than MQTT in IoT
  • No MDM support in Network Survey
  • No QR Configuration support in Netowrk Survey

Debugging:

  • Binary format not human-readable
  • Need special tools to inspect messages

Resources

Section titled “Resources”

Network Survey Messaging:

gRPC Resources:

Section titled “Related”