Network Survey Messaging API 1.6.0

The Network Survey Messaging API defines a set of messages that can be used to describe wireless survey related events. The messages range from cellular surveys such as GSM, CDMA, UMTS, LTE, and NR, to simple RF energy detection events.

NOTE: Despite the name "Network Survey Messaging API", this message specification is not exclusive to the Network Survey Android App. Instead, the Network Survey Android App is just one app that leverages Network Survey Messaging. Therefore, there are messages in this specification that do not apply to the Network Survey Android App (e.g. EnergyDetection).

While the most common use of these messages would be to send to an MQTT broker, this API specification simply defines the message schema. The transport or storage technology employed is purposefully left open to allow for these messages to flow over a variety of transports such as MQTT, gRPC, AMQP, etc. In addition, these messages can be written to disk by writing the JSON strings directly to a file to support unstructured data storage, or in a more structured approach such as a PostgreSQL or SQLite database.

Officially, the message schema support for the Network Survey Messaging API are the JSON defined messages from this document. However, protobuf definitions of these messages have been created as a convenience for a couple of reasons. First, it can make generating the JSON compliant messages easier and also converting the JSON messages to language specific objects. Secondly, it can allow for sending the messages in protocol buffer format instead of JSON if a compressed binary format is needed. It also has the side effect of supporting sending these messages over gRPC if Remote Procedure Call support is of interest. Check out the Network Survey Messaging Github README for more details.

Operations

  • RECEIVE gsm_message

    The gsm_message topic/channel is where GSM survey records can be published. For MQTT, set the MQTT topic as "gsm_message" and then publish a JSON message representing a GSM survey record in the format defined below.

    Operation IDgsm_message

    Accepts the following message:

    GSM Recordpublish.message

    Represents information recorded about a GSM tower at a particular time and geographic location.

    Message IDpublish.message
    object

    Examples

  • RECEIVE cdma_message

    The cdma_message topic/channel is where CDMA survey records can be published. For MQTT, set the MQTT topic as "cdma_message" and then publish a JSON message representing a CDMA survey record in the format defined below.

    Operation IDcdma_message

    Accepts the following message:

    CDMA Recordpublish.message

    Represents information recorded about a CDMA tower at a particular time and geographic location.

    Message IDpublish.message
    object

    Examples

  • RECEIVE umts_message

    The umts_message topic/channel is where UMTS survey records can be published. For MQTT, set the MQTT topic as "umts_message" and then publish a JSON message representing a UMTS survey record in the format defined below.

    Operation IDumts_message

    Accepts the following message:

    UMTS Recordpublish.message

    Represents information recorded about a UMTS NodeB at a particular time and geographic location.

    Message IDpublish.message
    object

    Examples

  • RECEIVE lte_message

    The lte_message topic/channel is where LTE survey records can be published. For MQTT, set the MQTT topic as "lte_message" and then publish a JSON message representing an LTE survey record in the format defined below.

    Operation IDlte_message

    Accepts the following message:

    LTE Recordpublish.message

    Represents information recorded about an LTE eNodeB at a particular time and geographic location.

    Message IDpublish.message
    object

    Examples

  • RECEIVE nr_message

    The nr_message topic/channel is where 5G NR survey records can be published. For MQTT, set the MQTT topic as "nr_message" and then publish a JSON message representing a 5G NR survey record in the format defined below.

    Operation IDnr_message

    Accepts the following message:

    5G NR Recordpublish.message

    Represents information recorded about a 5G NR gNodeB at a particular time and geographic location.

    Message IDpublish.message
    object

    Examples

  • RECEIVE 80211_beacon_message

    The 80211_beacon_message topic/channel is where 802.11 beacon survey records can be published. For MQTT, set the MQTT topic as "80211_beacon_message" and then publish a JSON message representing an 802.11 Access Point survey record in the format defined below.

    Operation ID80211_beacon_message

    Accepts the following message:

    Wi-Fi Beacon Recordpublish.message

    Represents information recorded about an 802.11 Access Point at a particular time and geographic location. 802.11 Beacon frames are sent by Access Points to advertise their existence and to provide all the necessary connection information. This message represents a capture of a single 802.11 Beacon message.

    Message IDpublish.message
    object

    Examples

  • RECEIVE 80211_probe_request_message

    The 80211_probe_request_message topic/channel is where 802.11 probe request survey records can be published. For MQTT, set the MQTT topic as "80211_probe_request_message" and then publish a JSON message representing an 802.11 Probe Request record in the format defined below. Added in 0.9.0

    Operation ID80211_probe_request_message

    Accepts the following message:

    Wi-Fi Probe Request Recordpublish.message

    Represents information recorded about an 802.11 Probe Request at a particular time and geographic location. 802.11 Probe Request frames are sent by clients looking to discover information about an Access Point with a specific SSID. This message represents a capture of a single 802.11 Probe Request message.

    Message IDpublish.message
    object

    Examples

  • RECEIVE 80211_deauthentication_message

    The 80211_deauthentication_message topic/channel is where 802.11 (Wi-Fi) Deauthentication Management Frames can be published. For MQTT, set the MQTT topic as "wifi_deauthentication_message". When a station wants to disassociate from another station, it invokes the deauthentication service. Deauthentication is a notification and cannot be refused. A station performs deauthentication by sending an authentication management frame (or group of frames to multiple stations) to advise of the termination of authentication.

    Operation ID80211_deauthentication_message

    Accepts the following message:

    Wi-Fi Deauthentication Recordpublish.message

    Represents an 802.11 deauthentication management frame. When a station wants to disassociate from another station, it invokes the deauthentication service. Deauthentication is a notification and cannot be refused. A station performs deauthentication by sending an authentication management frame (or group of frames to multiple stations) to advise of the termination of authentication.

    Message IDpublish.message
    object

    Examples

  • RECEIVE 80211_ota_message

    The 80211_ota_message topic/channel is where Over The Air (OTA) 802.11 (Wi-Fi) messages can be published. For MQTT, set the MQTT topic as "wifi_ota_message" and then publish a JSON message representing an OTA WiFi message.

    Operation ID80211_ota_message

    Accepts the following message:

    Wi-Fi Over The Air (OTA) Recordpublish.message

    Represents information recorded about an 802.11 packet recorded at a particular time and geographic location. This message represents a capture of a 802.11 packet in PCAP format.

    Message IDpublish.message
    object

    Examples

  • RECEIVE bluetooth_message

    The bluetooth_message topic/channel is where Bluetooth survey records can be published. For MQTT, set the MQTT topic as "bluetooth_message" and then publish a JSON message representing a Bluetooth survey record in the format defined below.

    Operation IDbluetooth_message

    Accepts the following message:

    Bluetooth Recordpublish.message

    Represents information recorded about a Bluetooth device at a particular time and geographic location. This message represents a capture of a signal Bluetooth frame.

    Message IDpublish.message
    object

    Examples

  • RECEIVE gnss_message

    The gnss_message topic/channel is where GNSS positioning records can be published. For MQTT, set the MQTT topic as "gnss_message" and then publish a JSON message in the format defined below.

    Operation IDgnss_message

    Accepts the following message:

    GNSS Recordpublish.message

    Represents information recorded about a Global Navigation Satellite System (GNSS) at a particular time and geographic location. Each record represents a single navigation message from a single satellite. These individual records are tied together using the group number field.

    Message IDpublish.message
    object

    Examples

  • RECEIVE energy_detection_message

    The energy_detection_message topic/channel is where RF energy detection records can be published. For MQTT, set the MQTT topic as "energy_detection_message" and then publish a JSON message in the format defined below.

    Operation IDenergy_detection_message

    Accepts the following message:

    Energy Detectionpublish.message

    Represents a General Purpose Radio (GPR) Energy Detection event. This survey record represents a general RF/PTT energy detection (i.e. RF energy was detected above a pre-defined threshold).

    Message IDpublish.message
    object

    Examples

  • RECEIVE signal_detection_message

    The signal_detection_message topic/channel is where signal detection records can be published. For MQTT, set the MQTT topic as "signal_detection_message" and then publish a JSON message in the format defined below.

    Operation IDsignal_detection_message

    Accepts the following message:

    Signal Detectionpublish.message

    Represents a General Purpose Radio (GPR) Signal Detection event. This survey record represents RF detections where the modulation and/or signal type could be determined. If both the modulation and signal type are unknown, then use the `energy_detection_message` instead.

    Message IDpublish.message
    object

    Examples

  • RECEIVE device_status_message

    The device_status_message topic/channel is where device status records can be published. This includes both DeviceStatus and PhoneState messages. For MQTT, set the MQTT topic as "device_status_message" and then publish a JSON message in one of the formats defined below.

    Operation IDdevice_status_message

    Accepts one of the following messages:

    • #0Device Statuspublish.message.0

      Represents a status message sent from the device to report its current state or to act as a heartbeat. The interval of this message can vary depending on use case.

      Message IDpublish.message.0
      object

      Examples

    • #1Phone Statepublish.message.1

      Represents the current state of the phone to include information about the currently registered networks. The interval of this message can vary depending on use case, but is typically sent when a change in the phone's state occurs, such as registering to a new network or being rejected from a network.

      Message IDpublish.message.1
      object

      Examples

  • RECEIVE cellular_ota_message

    The cellular_ota_message topic/channel is where Over The Air (OTA) cellular (LTE, UMTS/WCDMA) messages can be published. For MQTT, set the MQTT topic as "cellular_ota_message" and then publish a JSON message representing an OTA Cellular message.

    Operation IDcellular_ota_message

    Accepts one of the following messages:

    • #0GSM RR Signaling OTA Messagepublish.message.0

      Represents a raw GSM RR Signaling message sent Over The Air (OTA) between a GSM BTS and a GSM ME.

      Message IDpublish.message.0
      object

      Examples

    • #1UMTS NAS Messagepublish.message.1

      Represents a raw UMTS NAS message sent Over The Air (OTA) between a UMTS NodeB and a UMTS UE.

      Message IDpublish.message.1
      object

      Examples

    • #2WCDMA RRC OTA Messagepublish.message.2

      Represents a raw WCDMA RRC message sent Over The Air (OTA) between a UMTS NodeB and a UMTS UE.

      Message IDpublish.message.2
      object

      Examples

    • #3LTE RRC OTA Messagepublish.message.3

      Represents a raw LTE RRC message sent Over The Air (OTA) between an LTE eNodeB and an LTE UE.

      Message IDpublish.message.3
      object

      Examples

    • #4LTE NAS Messagepublish.message.4

      Represents a raw LTE NAS message sent Over The Air (OTA) between an LTE eNodeB and an LTE UE.

      Message IDpublish.message.4
      object

      Examples

Messages

  • #1GSM RecordgsmRecord

    Represents information recorded about a GSM tower at a particular time and geographic location.

    Message IDgsmRecord
    object
  • #2CDMA RecordcdmaRecord

    Represents information recorded about a CDMA tower at a particular time and geographic location.

    Message IDcdmaRecord
    object
  • #3UMTS RecordumtsRecord

    Represents information recorded about a UMTS NodeB at a particular time and geographic location.

    Message IDumtsRecord
    object
  • #4LTE RecordlteRecord

    Represents information recorded about an LTE eNodeB at a particular time and geographic location.

    Message IDlteRecord
    object
  • #55G NR RecordnrRecord

    Represents information recorded about a 5G NR gNodeB at a particular time and geographic location.

    Message IDnrRecord
    object
  • #6Wi-Fi Beacon RecordwifiBeaconRecord

    Represents information recorded about an 802.11 Access Point at a particular time and geographic location. 802.11 Beacon frames are sent by Access Points to advertise their existence and to provide all the necessary connection information. This message represents a capture of a single 802.11 Beacon message.

    Message IDwifiBeaconRecord
    object
  • #7Wi-Fi Probe Request RecordwifiProbeRequestRecord

    Represents information recorded about an 802.11 Probe Request at a particular time and geographic location. 802.11 Probe Request frames are sent by clients looking to discover information about an Access Point with a specific SSID. This message represents a capture of a single 802.11 Probe Request message.

    Message IDwifiProbeRequestRecord
    object
  • #8Wi-Fi Deauthentication RecordwifiDeauthenticationRecord

    Represents an 802.11 deauthentication management frame. When a station wants to disassociate from another station, it invokes the deauthentication service. Deauthentication is a notification and cannot be refused. A station performs deauthentication by sending an authentication management frame (or group of frames to multiple stations) to advise of the termination of authentication.

    Message IDwifiDeauthenticationRecord
    object
  • #9Wi-Fi Over The Air (OTA) RecordwifiOtaRecord

    Represents information recorded about an 802.11 packet recorded at a particular time and geographic location. This message represents a capture of a 802.11 packet in PCAP format.

    Message IDwifiOtaRecord
    object
  • #10Bluetooth RecordbluetoothRecord

    Represents information recorded about a Bluetooth device at a particular time and geographic location. This message represents a capture of a signal Bluetooth frame.

    Message IDbluetoothRecord
    object
  • #11GNSS RecordgnssRecord

    Represents information recorded about a Global Navigation Satellite System (GNSS) at a particular time and geographic location. Each record represents a single navigation message from a single satellite. These individual records are tied together using the group number field.

    Message IDgnssRecord
    object
  • #12Energy DetectionenergyDetection

    Represents a General Purpose Radio (GPR) Energy Detection event. This survey record represents a general RF/PTT energy detection (i.e. RF energy was detected above a pre-defined threshold).

    Message IDenergyDetection
    object
  • #13Signal DetectionsignalDetection

    Represents a General Purpose Radio (GPR) Signal Detection event. This survey record represents RF detections where the modulation and/or signal type could be determined. If both the modulation and signal type are unknown, then use the `energy_detection_message` instead.

    Message IDsignalDetection
    object
  • #14Device StatusdeviceStatus

    Represents a status message sent from the device to report its current state or to act as a heartbeat. The interval of this message can vary depending on use case.

    Message IDdeviceStatus
    object
  • #15Phone StatephoneState

    Represents the current state of the phone to include information about the currently registered networks. The interval of this message can vary depending on use case, but is typically sent when a change in the phone's state occurs, such as registering to a new network or being rejected from a network.

    Message IDphoneState
    object
  • #16LTE RRC OTA MessagelteRrc

    Represents a raw LTE RRC message sent Over The Air (OTA) between an LTE eNodeB and an LTE UE.

    Message IDlteRrc
    object
  • #17LTE NAS MessagelteNas

    Represents a raw LTE NAS message sent Over The Air (OTA) between an LTE eNodeB and an LTE UE.

    Message IDlteNas
    object
  • #18UMTS NAS MessageumtsNas

    Represents a raw UMTS NAS message sent Over The Air (OTA) between a UMTS NodeB and a UMTS UE.

    Message IDumtsNas
    object
  • #19WCDMA RRC OTA MessagewcdmaRrc

    Represents a raw WCDMA RRC message sent Over The Air (OTA) between a UMTS NodeB and a UMTS UE.

    Message IDwcdmaRrc
    object
  • #20GSM RR Signaling OTA MessagegsmSignaling

    Represents a raw GSM RR Signaling message sent Over The Air (OTA) between a GSM BTS and a GSM ME.

    Message IDgsmSignaling
    object

Schemas

  • object
  • object
  • object
  • object
  • object
  • object
  • object
  • object
  • object
  • object
  • object
  • object
  • object
  • object
  • object
  • object
  • object
  • object
  • object
  • object
  • version
    string

    The version number of the Network Survey Messaging API that this message is based off of.

  • deviceSerialNumber
    string

    The unique identifier for the device that captured this record. This should be consistent and should never change.

  • deviceName
    string

    A human readable name assigned to the device that captured this record. This value can change and is typically used as a human friendly display name.

  • deviceTime
    string
    format: date-time

    The timestamp of when this message was created in milliseconds formatted as an RFC3339 date-time. For example, '1996-12-19T16:39:57-08:00'.

  • latitude
    number
    format: double

    The latitude representing where this survey record was recorded.

  • longitude
    number
    format: double

    The longitude representing where this survey record was recorded.

  • altitude
    number
    format: float

    The altitude in meters above MSL representing where this survey record was recorded.

  • speed
    number
    format: float>= 0

    The speed at the time of this record capture in meters per second. This field was added in version 0.11.0. From the Network Survey Android app, this field is only present if it is detected that the device is in motion.

  • missionId
    string

    A unique name for this particular run of a survey. The timestamp of when the survey was started is typically included, or the mission ID might contain a user entered value to enable them to uniquely identify the purpose of this survey.

  • recordNumber
    integer
    format: int32>= 1

    Starts at 1 and each subsequent record should have its number incremented by 1.

  • groupNumber
    integer
    format: int32>= 1

    Starts at 1 and each subsequent scan should have its number incremented by 1. For simple frequency sweeps, all detections in the same sweep should have the same group number. For cellular surveys, each scan of the serving cell and neighbor cells should have the same group number.

  • signalStrength
    number
    format: float[ -200 .. 200 ]

    The signal strength of the received signal in dBm.

  • deviceModel
    string

    The model number of the device that this message originated from.

  • appVersion
    string

    The version of the software application that this message originated from (most likely the Network Survey Android app, but could be any other app). Added in version 1.3.0.

  • accuracy
    integer
    format: int32>= 0

    The estimated horizontal accuracy of the provided location, radial, in meters. We define horizontal accuracy as the radius of 68% confidence. In other words, if you draw a circle centered at this location's latitude and longitude, and with a radius equal to the accuracy, then there is a 68% probability that the true location is inside the circle. A value of 0 indicates there was no available horizontal accuracy.

  • heading
    number
    format: float[ -180 .. 180 ]

    Heading of the sensor/antenna, in degrees from true north. One can use sensor orientation (heading, pitch, roll) and sensor characteristics (fieldofView, receiverSensitivity) to form more accurate estimates of the transmitter's position.

  • pitch
    number
    format: float[ -180 .. 180 ]

    Pitch of the sensor/antenna, in degrees from the ground plane. One can use sensor orientation (heading, pitch, roll) and sensor characteristics (fieldofView, receiverSensitivity) to form more accurate estimates of the transmitter's position.

  • roll
    number
    format: float[ -180 .. 180 ]

    Roll of the sensor/antenna, in degrees from the ground plane. One can use sensor orientation (heading, pitch, roll) and sensor characteristics (fieldofView, receiverSensitivity) to form more accurate estimates of the transmitter's position.

  • fieldOfView
    number
    format: float[ 0 .. 360 ]

    The horizontal field of view of the sensor/antenna in degrees. If absent, then this assumes that the sensor has a 360 degree field of view (i.e. omnidirectional antenna). One can use sensor orientation (heading, pitch, roll) and sensor characteristics (fieldofView, receiverSensitivity) to form more accurate estimates of the transmitter's position.

  • receiverSensitivity
    number
    format: float>= 0

    The minimum signal strength that a receiver can detect, in units of dBm. One can use sensor orientation (heading, pitch, roll) and sensor characteristics (fieldOfView, receiverSensitivity) to form more accurate estimates of the transmitter's position or distance from the sensor.

  • provider
    string

    The company providing the cellular service.

  • mcc
    integer
    format: int32>= 0

    Mobile Country Code, 3 digits.

  • mnc
    integer
    format: int32>= 0

    Mobile Network Code, used in conjunction with MCC (PLMN) to identify a carrier, 2 to 3 digits.

  • servingCell
    boolean

    Boolean indicating if this record represents a serving cell record, or a neighbor cell record. If the field is unset then it is unknown if this record is for the serving cell or a neighbor cell. A value of true indicates that the record represents a serving cell, a value of false indicates a neighbor record.

  • slot
    integer

    The slot number of the SIM card or radio slot that this record was captured from. This enables support for multiple SIM cards in a single device or multiple radios in a single device. Numbering does not start at 0 or 1, and can be any arbitrary number. Therefore, the number does not reveal anything about the number of SIM cards or radio slots in the device. This field is optional, and if it is not present that is an indication that the device only has a single SIM card or radio (but the presence of this field does not indicate multiple SIM cards or radios). Added in version 0.15.0.

  • lac
    integer
    format: int32[ 0 .. 65535 ]

    Location Area Code, location code inside a PLMN, valid range 0-65535.

  • ci
    integer
    format: int32[ 0 .. 65535 ]

    Cell Identity of the measured cell, valid range 0-65535.

  • arfcn
    integer
    format: int32>= 0

    Absolute Radio Frequency Channel Number, valid values defined in 3GPP TS 45.005 Release 10 Section 2.

  • bsic
    integer
    format: int32[ 0 .. 63 ]

    Base Station Identity Code, consists of NCC and BCC, valid range 0-63 (in octal). For example, a BSIC of 38 maps to an NCC of 4 and BCC of 6.

  • sid
    integer
    format: int32[ 0 .. 32767 ]

    System Identification Number, 15 bit number that represents the service provider(s) a base station provides service to.

  • nid
    integer
    format: int32[ 0 .. 65535 ]

    Network Identification Number, 16 bit number that represents the network within a SID.

  • zone
    integer
    format: int32>= 0

    A collection of one or more base stations treated as a unit when determining whether a mobile station should perform zone-based registration.

  • bsid
    integer
    format: int32[ 0 .. 65535 ]

    Base Station Identifier. Exclusively identifies a base station under a SID/NID.

  • channel
    integer
    format: int32>= 0

    Channel number that corresponds to a frequency.

  • pnOffset
    integer
    format: int32[ 0 .. 511 ]

    Pseudo Random Noise, 0-511, used to differentiate sectors on base stations.

  • ecio
    number
    format: float

    Measure of the quality / cleanliness of the signal from the tower to the modem (signal to noise). Energy per chip to Interference power ratio measured in dB.

  • cid
    integer
    format: int32[ 0 .. 268435455 ]

    The Cell Identity of the measured cell, 28 bits, the RNC-ID is the first 12 bits, and the C-ID is the last 16 bits, valid range 0-268435455. Defined in 3GPP TS 25.331.

  • uarfcn
    integer
    format: int32[ 0 .. 13096 ]

    UTRA Absolute Radio Frequency Channel Number (Downlink), valid range 0-13096, defined in 3GPP TS 25.101 and 3GPP TS 25.102.

  • psc
    integer
    format: int32[ 0 .. 511 ]

    Primary Scrambling Code, valid range 0-511.

  • rscp
    number
    format: float

    Reference Signal Code Power in dBm.

  • ecno
    number
    format: float

    Received energy per chip divided by the power density in the band in dB. The value is negative as the RSCP is smaller than the total received power. Added in version 0.8.0.

  • tac
    integer
    [ 0 .. 65535 ]

    Tracking Area Code, location code inside a PLMN, valid range 0-65535.

  • eci
    integer
    [ 0 .. 268435455 ]

    ECI, the Cell Identity of the measured cell, 28 bits. The Macro eNB ID is the first 20 bits of the Cell Identity and the last 8 bits represent the sector. Valid range 0-268435455.

  • earfcn
    integer
    format: int32[ 0 .. 262143 ]

    Downlink E-UTRA Absolute Radio Frequency Channel Number, valid range 0-262143, defined in 3GPP TS 36.331 version 14.2.2 Release 14 page 567.

  • pci
    integer
    format: int32[ 0 .. 503 ]

    Physical Cell Identity, valid range 0-503.

  • rsrp
    number
    format: float[ -140 .. -44 ]

    Reference Signal Received Power in dBm, valid range -44 to -140, corresponding to RSRP_97 to RSRP_00 respectively.

  • rsrq
    number
    format: float[ -19.5 .. -3 ]

    Reference Signal Received Quality in dB, valid range -3 to -19.5, corresponding to RSRQ_34 to RSRQ_00 respectively.

  • cqi
    integer
    format: int32[ 0 .. 15 ]

    Channel Quality Indicator, used by the UE to notify the serving cell (eNodeB) about the quality of the downlink channel, valid range 0-15. This field was added in version 0.14.0.

  • lteBandwidth
    string

    The LTE downlink bandwidth in MHz (one of 1.4, 3, 5, 10, 15, 20).

      Allowed values:
    • "UNKNOWN"
    • "MHZ_1_4"
    • "MHZ_3"
    • "MHZ_5"
    • "MHZ_10"
    • "MHZ_15"
    • "MHZ_20"
  • nrTac
    integer
    [ 0 .. 16777215 ]

    NR Tracking Area Code, location code inside a PLMN, valid range 0 - 16,777,215 as defined in 3GPP TS 38.331 version 16.2.0 Release 16 page 643.

  • nci
    string
    format: int64[ 0 .. 68719476735 ]

    NCI, the Cell Identity of the measured cell, 36 bits. The gNB ID is the first 22-32 bits of the NCI and the remaining bits represent the sector. Valid range 0 - 68,719,476,735 as defined in 3GPP TS 38.331 version 16.2.0 Release 16 page 370.

  • narfcn
    integer
    format: int32[ 0 .. 3279165 ]

    Downlink NR Absolute Radio Frequency Channel Number, valid range 0 - 3,279,165, defined in 3GPP TS 38.331 version 16.2.0 Release 16 page 784.

  • nrPci
    integer
    format: int32[ 0 .. 1007 ]

    NR Physical Cell Identity, valid range 0-1007 as defined in 3GPP TS 38.331 version 16.2.0 Release 16 page 503.

  • ssRsrp
    number
    format: float[ -156 .. -31 ]

    Secondary Synchronization signal Reference Signal Received Power in dBm, valid range -156 to -31, corresponding to RSRP_1 to RSRP_126 respectively as defined in 3GPP TS 38.133 version 16.5.0 Release 16 Table 10.1.6.1-1.

  • ssRsrq
    number
    format: float[ -43 .. 20 ]

    Secondary Synchronization signal Reference Signal Received Quality in dB, valid range -43 to 20, corresponding to SS-RSRQ_1 to SS-RSRQ_127 respectively (increments of 0.5) as defined in 3GPP TS 38.133 version 16.5.0 Release 16 Table 10.1.11.1-1.

  • ssSinr
    number
    format: float[ -23 .. 40 ]

    Secondary Synchronization signal signal-to-noise and interference ratio in dB. The reporting range of SS-SINR is defined from -23 dB to 40 dB with 0.5 dB resolution, corresponding to SINR_1 to SINR_127 respectively as defined in 3GPP TS 38.133 version 16.5.0 Release 16 Table 10.1.16.1-1.

  • csiRsrp
    number
    format: float[ -140 .. -44 ]

    Channel State Information (CSI) Reference Signal Received Power in dBm, valid range -140 to -44, corresponding to RSRP_17 to RSRP_113 respectively as defined in 3GPP TS 38.133 version 16.5.0 Release 16 Table 10.1.6.1-1.

  • csiRsrq
    number
    format: float

    CSI Reference Signal Received Quality in dB.

  • csiSinr
    number
    format: float[ -23 .. 40 ]

    CSI signal-to-noise and interference ratio in dB. The reporting range of CSI-SINR is defined from -23 dB to 40 dB with 0.5 dB resolution, corresponding to SINR_1 to SINR_127 respectively as defined in 3GPP TS 38.133 version 16.5.0 Release 16 Table 10.1.16.1-1.

  • sourceAddress
    string

    Source MAC Address, the original source of the frame.

  • destinationAddress
    string

    Destination MAC Address, the final destination of the frame.

  • bssid
    string

    Basic Service Set Identifier, the MAC Address of the Access Point.

  • beaconInterval
    integer
    format: int32>= 0

    Beacon Interval, in milliseconds. The rate at which beacon frames are sent from an Access Point advertising the existence of the AP.

  • serviceSetType
    string

    The Service Set Type that this node belongs to.

      Allowed values:
    • "UNKNOWN"
    • "BSS"
    • "ESS"
    • "BSS_ESS"
    • "IBSS"
    • "MBSS"
  • ssid
    string

    The Service Set Identifier (aka the Wi-Fi network name), UTF-8 Encoded.

  • supportedRates
    string

    A list of data rates supported by this device separated by semicolons.

  • extendedSupportedRates
    string

    An extended list of data rates supported by this device separated by semicolons.

  • array<string>

    A list of the supported cipher suites. See IEEE Std 802.11-2012 Section 8.4.2.27.2 for more details on the 802.11 Cipher Suites.

  • array<string>

    A list of the supported Authentication and Key Management (AKM) suites. See IEEE Std 802.11-2012 Section 8.4.2.27.3 for more details on the 802.11 AKM Suites.

  • encryptionType
    string

    The encryption type used by the Access Point. This field should be kept in sync with the cipherSuites field as it is directly related.

      Allowed values:
    • "UNKNOWN"
    • "OPEN"
    • "WEP"
    • "WPA"
    • "WPA_WPA2"
    • "WPA2"
    • "WPA3"
    • "WPA2_WPA3"
  • wps
    boolean

    Boolean indicating if this Access Point supports Wi-Fi Protected Setup as defined by the Wi-Fi Alliance.

  • passpoint
    boolean

    Boolean indicating if this is a Passpoint Enabled Network Access Point. Passpoint is a standard defined by the Wi-Fi Alliance, not IEEE. This field was added in version 0.13.0.

  • nodeType
    string

    The type of station that sent this frame.

      Allowed values:
    • "UNKNOWN"
    • "AP"
    • "NON_AP_STA"
    • "STA"
  • standard
    string

    The 802.11 standard being employed by the device.

      Allowed values:
    • "UNKNOWN"
    • "IEEE80211"
    • "IEEE80211A"
    • "IEEE80211B"
    • "IEEE80211G"
    • "IEEE80211BG"
    • "IEEE80211N"
    • "IEEE80211AC"
    • "IEEE80211AX"
    • "IEEE80211BE"
  • reason
    integer
    format: int32[ 0 .. 65535 ]

    Clients may disassociate prior to powering off. APs may disassociate clients for various reasons including failure to properly authenticate, for load balancing or timeout reasons, entering a state of maintenance, etc. The 802.11-2016 standard includes a list of disassociation reasons.

  • txPower
    number
    format: float[ -200 .. 200 ]

    The power in dBm that the device used to transmit the signal.

  • technology
    string

    The Bluetooth wireless technology system that is used in this frame. See the BLUETOOTH SPECIFICATION Version 5.0 | Vol 1, Part A Section 1 (page 166) for more details.

      Allowed values:
    • "UNKNOWN"
    • "BR_EDR"
    • "LE"
  • supportedTechnologies
    string

    The Bluetooth wireless technology systems that are supported be the transmitting device. See the BLUETOOTH SPECIFICATION Version 5.0 | Vol 1, Part A Section 1 (page 166) for more details.

      Allowed values:
    • "UNKNOWN"
    • "BR_EDR"
    • "LE"
    • "DUAL"
  • otaDeviceName
    string

    The Bluetooth device name is the user-friendly name that a Bluetooth device exposes to remote devices. See the BLUETOOTH SPECIFICATION Version 5.0 | Vol 3, Part C Section 3.2.2 (page 1988) for more details.

  • constellation
    string

    The satellite constellation associated with the record.

      Allowed values:
    • "UNKNOWN"
    • "GPS"
    • "GLONASS"
    • "GALILEO"
    • "BEIDOU"
    • "SBAS"
    • "QZSS"
    • "IRNSS"
  • spaceVehicleId
    integer
    format: int32>= 0

    The identifier for the space vehicle (SV).

  • carrierFreqHz
    integer
    format: int64>= 1

    The carrier frequency utilized by the SV, in Hz.

  • clockOffset
    number
    format: double

    The clock offset calculated by the receiver based on the space-vehicle time contained in a received navigation message, i.e. the time it took for a given navigation message to be sent from a space vehicle to the receiver's antenna, as calculated by the receiver itself.

  • usedInSolution
    boolean

    Indicates whether this particular satellite data was used as part of the solution. A value of true indicates that the record was used in the solution, a value of false indicates that the record was not used in the solution.

  • undulationM
    number
    format: float[ -150 .. 150 ]

    The height in meters of the geoid at a given point, relative to a given reference ellipsoid, i.e. the difference in height between the 'real' surface (ignoring topographical features) and a 'modeled' surface given by a reference ellipsoid such as the one defined by WGS84. Valid range, -150.0 to 150.0.

  • latitudeStdDevM
    number
    format: float>= 0

    The standard deviation of the latitude measurement in meters, where a higher value indicates a less precise position lock. For example, a 5m deviation indicates that, with 68% confidence, the latitude is within 5m of the reported position; with 95% confidence, the latitude is within 10m of the reported position, etc. This relates to the Horizontal Dilution of Precision (HDOP).

  • longitudeStdDevM
    number
    format: float>= 0

    The standard deviation of the longitude measurement in meters, where a higher value indicates a less precise position lock. For example, a 5m deviation indicates that, with 68% confidence, the longitude is within 5m of the reported position; with 95% confidence, the longitude is within 10m of the reported position, etc. This relates to the Horizontal Dilution of Precision (HDOP).

  • altitudeStdDevM
    number
    format: float>= 0

    The standard deviation of the altitude measurement in meters, where a higher value indicates a less precise position lock. For example, a 5m deviation indicates that, with 68% confidence, the altitude is within 5m of the reported position; with 95% confidence, the altitude is within 10m of the reported position, etc. This relates to the Vertical Dilution of Position (VDOP), and tends to be higher than the Lat/Lon standard deviations due to GNSS satellites being above GNSS receivers.

  • agcDb
    number
    format: float[ -50 .. 50 ]

    Automatic Gain Control, measured in dB. Valid range, -50.0 to 50.0

  • cn0DbHz
    number
    format: float[ -100 .. 100 ]

    The Carrier-to-noise density in dB-Hz, which represents the measured C/N0 for the signal at the antenna inputCarrier to noise density ratio, measured in dB-Hz. Typical range: 10-50 dB-Hz. The range of possible C/N0 values is 0-63 dB-Hz to handle some edge cases.

  • hdop
    number
    format: float[ 0 .. 50 ]

    Horizontal Dilution of Precision. Valid range, 0.0 to 50.0.

  • vdop
    number
    format: float[ 0 .. 50 ]

    Vertical Dilution of Precision. Valid range, 0.0 to 50.0.

  • frequencyHz
    integer
    format: int64>= 1

    The frequency, in Hz, that the radio signal was received on.

  • bandwidthHz
    integer
    format: int32>= 1

    The bandwidth, in Hz, of the received signal.

  • snr
    number
    format: float

    The Signal to Noise Ratio of the received signal to the noise power measured in dB. A ratio higher than 1:1 (greater than 0 dB) indicates more signal than noise.

  • timeUp
    string
    format: date-time

    The date & time the energy/signal was detected as active. This is formatted as an RFC3339 date-time. For example, '1996-12-19T16:39:57-08:00'.

  • durationSec
    number
    format: float> 0

    The duration of time, in seconds, that the signal was detected as active.

  • modulation
    string

    The modulation type found on the received signal. It is appropriate to leave this blank if the modulation of the signal is unknown, but either the modulation or signalName field should be filled out. If neither of them are known then the energyDetection message should be used instead.

  • signalName
    string

    The modulation type found on the received signal. It is appropriate to leave this blank if the modulation of the signal is unknown, but either the modulation or signalName field should be filled out. If neither of them are known then the energyDetection message should be used instead.

  • batteryLevelPercent
    integer
    format: int32[ 0 .. 100 ]

    The percentage of battery remaining (if the device has a battery).

  • object

    If present, represents that the device is in an error state.

  • mdmOverride
    boolean

    Indicates if the device currently has the Mobile Device Management (MDM) Override option turned on. If true, the user has forced the MDM options off, if false, the user has left the MDM control in place. Added in version 0.9.0.

  • simState
    string

    The current state of the SIM card. The values are taken directly from android.telephony.TelephonyManager#SimState and should be kept in sync with those values. Even the order lines up exactly, which makes conversion easier.

      Allowed values:
    • "UNKNOWN"
    • "ABSENT"
    • "PIN_REQUIRED"
    • "PUK_REQUIRED"
    • "NETWORK_LOCKED"
    • "READY"
    • "NOT_READY"
    • "PERM_DISABLED"
    • "CARD_IO_ERROR"
    • "CARD_RESTRICTED"
    • "LOADED"
    • "PRESENT"
  • simOperator
    string

    The PLMN portion of the SIM's IMSI. This indicates the provider that issued the SIM card. The format is the MCC and MNC concatenated as one string. Can be 5 or 6 digits in length where the MCC is always 3 digits and the MNC is either 2 or 3.

  • object

    A network that this device is registered to, or tried to register to.

  • object

    Contains the information about a particular GSM cell.

  • object

    Contains the information about a particular CDMA cell.

  • object

    Contains the information about a particular UMTS cell.

  • object

    Contains the information about a particular LTE cell.

  • object

    Contains the information about a particular NR cell.

  • pcapRecord
    string
    format: byte

    The raw cellular message bytes encoded in base64. The bytes in this field are the raw message bytes captured from the Over The Air (OTA) cellular radio frame with the appropriate PCAP headers as the prefix. In other words, the bytes are the same bytes that would show up in a pcap file for a cellular message. The general structure consists of a PCAP record header, PPI header, layer 3 header, layer 4 header, a GSMTAP header, followed by the cellular OTA message. Using this structure means that Wireshark, tshark or any other tool that can read GSMTAP pcap records can easily parse out the contents of this message. For more details see the Network Survey+ Android App Source Code.

  • frameType
    integer
    format: int32[ 0 .. 3 ]

    The frame type of the 802.11 message. The frame type represents the type of 802.11 frame that the pcapRecord field contains. For example, a frame type of 0 represents a management frame, 1 represents a control frame, and 2 represents a data frame, and 3 represents an extension.

  • frameSubtype
    integer
    format: int32>= 0

    The subtype of the 802.11 message that corresponds to the frame type. The frame subtype represents the subtype of the 802.11 frame that the pcapRecord field contains. For example, if the frame type is 0 (aka Management) a frame subtype of 0 represents an association request, 1 represents an association response, 2 represents a reassociation request, etc.

  • channelType
    string

    The channel type that this message was sent on. The channel type represents the logical channel that the raw cellular message was sent over.