URWB Telemetry Protocol 2.0.19
Available Languages
URWB Telemetry Protocol
Unified Industrial Wireless (UIW)
Software Release 17.13.1
| Revision |
2.0 REV. 19 |
| Last Modification Date |
Jan 16th 2024 |
Table of Contents
FHCTRL_VEHICLE TLV (Type: 0x001)
FHCTRL_VEHICLE_MULTI_RADIO TLV (Type: 0x01D)
TX_STATS_MULTI_RADIO TLV (Type: 0x01E)
RX_STATS_MULTI_RADIO TLV (Type: 0x01F)
HANDOFF_TBL_MULTI_RADIO TLV (Type: 0x021)
AGGR_TRAFFIC_MULTI_RADIO TLV (Type: 0x022)
RADIO_CFG_MULTI_RADIO TLV (Type: 0x023)
HANDOFF_TBL_MULTI_RADIO_MPO TLV (Type: 0x025)
BLOCKLIST MULTI-RADIO TLV (Type: 0x026)
Introduction
URWB Industrial Wireless series products support the transmission of a network data stream to provide real-time telemetry statistics regarding the status and performance of the vehicular connection to listening applications.
Bias-Free Language
The documentation set for this product strives to use bias-free language. For this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, the language used based on RFP documentation, or language that is used by a referenced third-party product.
Definitions
All word (16-bit) and dword (32-bit) fields are stored in network byte order (big endian).
Fields marked as reserved must be ignored.
Timestamps are stored in the following timeval32 format:
Table 1 - Definition of timeval32 structure
| OFFSET |
TYPE |
VALUE |
DESCRIPTION |
| 0 |
dword |
tv_sec |
seconds |
| 4 |
dword |
tv_usec |
micro seconds |
Packet Format
Telemetry is sent using UDP packets to a user-specified IP address and port number (default 30000). The source port number is 647.
The packet starts with a main header followed by a variable number of Type-Length-Value fields (TLV). The general structure of a TLV is the following:
Table 2 - General structure of a TLV
| OFFSET |
TYPE |
VALUE |
DESCRIPTION |
| 0 |
word |
TYPE |
Record type: b0-b11: TLV type (see below) b12-b15: Reserved |
| 2 |
word |
LEN |
Record length in bytes: b0-b11: Length of TLV data (without header) b12-b15: Reserved |
| 4 |
byte[LEN] |
DATA |
TLV content |
Unless where explicitly noted, the TLVs defined in this document have been available since release 17.12.1.
Main Header
Table 3 - Main header
| OFFSET |
TYPE |
VALUE |
DESCRIPTION |
| 0 |
dword |
0xF1CA0005 |
Magic number for protocol identification |
| 4 |
dword |
FLAGS |
Message flags b0: TLV type (1 = command tlv) b1: Assured forwarding. If set, guaranteed delivery to the consumer (Monitor) is required. For this kind of message, the sequence number must be ignored and the message must be processed anyway. b1-b31: Reserved |
| 8 |
dword |
MESH_ID |
Mesh ID of the unit that generated the info |
| 12 |
dword |
VEHICLE_ID |
Vehicle ID of the unit that generated the info |
| 16 |
dword |
MESHEND_ID |
Current mesh-end ID for this unit |
| 20 |
dword |
SEQ |
Sequence number of this message |
| 24 |
timeval32 |
TS_REF |
Timestamp of this message Clock source: internal |
| 32 |
TLV[] |
TLV |
Sequence of TLVs |
FHCTRL_VEHICLE TLV (Type: 0x001)
This TLV contains a fixed fhctrl_state header followed by a variable number of fhctrl_entry structures. The number can be calculated as N = (TLV_LEN - sizeof(fhctrl_state)) / sizeof(fhctrl_entry). This TLV is written by mobile units only.
Table 4 - Definition of fhctrl_state structure
| OFFSET |
TYPE |
VALUE |
DESCRIPTION |
| 0 |
dword |
CURR_SBR |
Infrastructure unit for current handoff (attempt) |
| 4 |
dword |
CURR_MBR |
Mobile unit current handoff (attempt) |
| 8 |
dword |
CURR_SEQ |
Sequence number of current handoff |
| 12 |
timeval32 |
HO_TIME |
Timestamp of last handoff event (attempt, success, failure, etc) |
| 20 |
byte |
HO_RETRIES |
Number of retries attempted before success or failure |
| 21 |
byte |
HO_FLAGS |
b6 = Pending b7 = Failed |
| 22 |
dword |
HO_AGE |
Milliseconds since last successful handoff event |
| 26 |
dword |
DOP |
The unit’s own DoP b0-b15: DoP value b16-b31: Color information |
| 30 |
word |
FLAGS |
b0 = Wireless relay b1 = CanAccept b2 = IsCritical b3 = Frequency Scan in progress |
| 32 |
word |
INHIBIT |
Inhibition mask |
The definition of the fhctrl_entry structure is the following:
Table 5 - Definition of fhctrl_entry structure
| OFFSET |
TYPE |
VALUE |
DESCRIPTION |
| 0 |
dword |
SBR_ID |
Mesh ID of infrastructure unit |
| 4 |
dword |
MBR_ID |
Mesh ID of mobile unit |
| 8 |
dword |
DOP |
Advertized DoP, as received from the remote unit b0-b15: DoP value b16-b31: Color information |
| 12 |
word |
CHAN_INFO |
Channel number and width, encoded as follows: b0-b7: channel number (1-255) b8-b11: reserved (zero) 1 = 20 MHz 2 = 40 MHz HT- 3 = 40 MHz HT+ 4 = 5 MHz 5 = 10 MHz 6 = 80 MHz 7 = 160 MHz Other values: invalid |
| 14 |
word |
AGE |
Milliseconds since last update of this entry |
| 16 |
byte |
RSSI |
Current RSSI |
| 17 |
byte |
FLAGS |
0x00 (to be defined) b1-b3 = Reserved b4 = active link |
TITAN TLV (Type: 0x00A)
This TLV contains information about Titan’s fast-failover events. It is generated whenever one of the supported failover cases occurs.
Table 16 - Definition of Titan TLV (struct titan_header)
| OFFSET |
TYPE |
VALUE |
DESCRIPTION |
| 0 |
byte |
TYPE |
b0-b3: Event type 0 = Generic topology change 1 = Mobile failover 2 = Mesh End failover 3 = Reserved 4 = Global Gateway failover |
| 1 |
byte |
FLAGS |
b0-b3: Event Reason 0 = Unspecified 1 = Link failure 2 = Node Failure 3 = Reserved 4 = Recovery b4: Event domain 0 = Local, 1 = Remote |
| 2 |
timeval32 |
TIMESTAMP |
Timestamp of topology event (0 = not available) |
| 10 |
dword |
COUNT |
Event counter (Titan only, might be zero otherwise) |
| 14 |
dword |
MASTER |
Mesh-ID of primary unit, as resulting after the event |
| 18 |
dword |
BACKUP |
Mesh-ID of previous master unit (optional, can be 0.0.0.0 if not available) |
ETH_TPT TLV (Type: 0x00D)
This TLV contains information about each ethernet link. This TLV contains an ETH_TPT structure followed by multiple ETH_ENTRY structures, for each destination. Each structure contains a throughput value for that neighbor. The number can be calculated as N = ((TLV_LEN - sizeof(struct eth_tpt)) / sizeof(struct eth_entry)). The TLV contains NUM_TX entries followed by NUM_RX = N-NUM_TX entries.
Table 8 - Definition of ETH_TPT TLV structure
| OFFSET |
TYPE |
VALUE |
DESCRIPTION |
| 0 |
word |
NUM_TX |
Number of TX entries, preceding RX entries |
Table 19 - Definition of ETH_ENTRY structure
| OFFSET |
TYPE |
VALUE |
DESCRIPTION |
| 0 |
dword |
SRC_IP |
IP address of source station |
| 4 |
dword |
DST_IP |
IP address of destination station |
| 8 |
dword |
TPT |
throughput value for the specific link |
| 12 |
dword |
PKTS |
Number of packets transmitted by this flow |
MULTIPATH TLV (Type: 0x01B)
This TLV contains information about each redundant MPO LSP established by the node. Each LSP is represented by a lsp_multipath_route structure. Each TLV contains several lsp_multipath_route structures as many as the number of LSP routes established by the node.
An empty route (NUM_PEERS = 1) means that the multipath table contains no entry for the destination unit identified by PEERS[0]. In some cases, this can be used to provide an explicit notification that certain redundant paths to some mesh IDs have been deleted. For such entries, the MPO Path ID and AGE fields are not meaningful and must be ignored.
The definition of the lsp_multipath_route structure is the following:
Table 31 - Definition of lsp_multipath_route structure
| OFFSET |
TYPE |
VALUE |
DESCRIPTION |
| 0 |
byte |
FLAGS |
b0: Mobility LSP b1: Reserved b2: Destination is the Global Gateway b3-b6: Reserved (zero) b5-b7: MPO Path ID |
| 1 |
byte |
NUM_PEERS |
Number of peers of the LSP route If NUM_PEERS = 1, this is an empty route. |
| 2 |
word |
AGE |
Seconds since the LSP was refreshed |
| 4 |
dword[NUM_PEERS] |
PEERS |
Array of Mesh ID in the LSP route, as follows: b0-b23: lowest 3 octets of the Mesh ID b24-b27: Local interface ID (0,5=N/A; 1,2=wired; 3,4=wireless) b28-b31: Remote interface ID to next hop (same as above) |
FHCTRL_VEHICLE_MULTI_RADIO TLV (Type: 0x01D)
This TLV contains a fixed fhctrl_state header followed by a variable number of fhctrl_entry structures. The number can be calculated as N = (TLV_LEN - sizeof(fhctrl_state)) / sizeof(fhctrl_entry). This TLV is written by mobile units only.
Table 33 - Definition of fhctrl_state structure
| OFFSET |
TYPE |
VALUE |
DESCRIPTION |
| 0 |
dword |
CURR_SBR |
Infrastructure unit's interface IP for current handoff (attempt) (MeshID for legacy stations) |
| 4 |
dword |
CURR_MBR |
Mobile unit's interface IP for current handoff (attempt) (MeshID for legacy stations) |
| 8 |
dword |
CURR_SEQ |
Sequence number of current handoff |
| 12 |
timeval32 |
HO_TIME |
Timestamp of last handoff event (attempt, success, failure, etc) |
| 20 |
byte |
HO_RETRIES |
Number of retries attempted before success or failure |
| 21 |
byte |
HO_FLAGS |
b6 = Pending b7 = Failed |
| 22 |
dword |
HO_AGE |
Milliseconds since last successful handoff event |
| 26 |
dword |
DOP |
The unit’s own DoP b0-b15: DoP value b16-b31: Color information |
| 30 |
word |
FLAGS |
b0 = Wireless relay b1 = CanAccept b2 = IsCritical b3 = Frequency Scan in progress |
| 32 |
word |
INHIBIT |
Inhibition mask |
The definition of the fhctrl_entry structure is the following:
Table 34 - Definition of fhctrl_entry structure
| OFFSET |
TYPE |
VALUE |
DESCRIPTION |
| 0 |
dword |
SBR_ID |
Interface IP of infrastructure unit |
| 4 |
dword |
MBR_ID |
Interface IP of mobile unit |
| 8 |
dword |
DOP |
Advertized DoP, as received from the remote unit b0-b15: DoP value b16-b31: Color information |
| 12 |
word |
CHAN_INFO |
Channel number and width, encoded as follows: b0-b7: channel number (1-255) b8-b11: reserved (zero) 1 = 20 MHz 2 = 40 MHz HT- 3 = 40 MHz HT+ 4 = 5 MHz 5 = 10 MHz 6 = 80 MHz 7 = 160 MHz Other values: invalid |
| 14 |
word |
AGE |
Milliseconds since last update of this entry |
| 16 |
byte |
RSSI |
Current RSSI |
| 17 |
byte |
FLAGS |
0x00 (to be defined) b1-b3 = Reserved b4 = active link |
TX_STATS_MULTI_RADIO TLV (Type: 0x01E)
This TLV contains a variable number of TX_STATS structures. The number can be calculated as the length of the TLV divided by the size of (TX_STATS).
Table 35 - Definition of TX_STATS structure
| OFFSET |
TYPE |
VALUE |
DESCRIPTION |
| 0 |
dword |
SRC_IP |
Interface IP address of source station (MeshID for legacy stations) |
| 4 |
dword |
DST_IP |
Interface IP address of destination station (MeshID for legacy stations) |
| 8 |
dword |
SENT |
Number of transmitted packets |
| 12 |
dword |
RETRIES |
Number of transmission retries |
| 16 |
dword |
FAILED |
Number of lost packets (TX errors) |
| 20 |
dword |
BYTES |
Number of bytes transmitted to SRC_MAC |
| 24 |
word |
AGE |
Milliseconds since last TX feedback |
| 26 |
byte |
TX_FLAGS |
TX flags for last TX packets to this station bit 0: 40 MHz bit 4-5: TX_MCS type: 0 = no HT, 1 = HT, 2 = VHT, 3=HE bit 6-7: GI (0=0.8uS, 1=0.4uS, 2=1.6uS 3=3.2uS) |
| 27 |
byte |
TX_MCS |
From TX feedback. The encoding depends on the “TX_MCS type” field of TX_FLAGS and it is defined as follows: In HT mode the MCS is a value in the range 0-15, with bit 3 indicating whether the packet was transmitted in single or double stream MIMO mode. b6-b7: reserved |
RX_STATS_MULTI_RADIO TLV (Type: 0x01F)
This TLV contains a variable number of RX_STATS structures. The number can be calculated as the length of the TLV divided by the size of (RX_STATS).
Table 36 - Definition of RX_STA structure
| OFFSET |
TYPE |
VALUE |
DESCRIPTION |
| 0 |
dword |
SRC_IP |
Interface IP address of source station (MeshID for legacy stations) |
| 4 |
dword |
DST_IP |
Interface IP address of destination station (MeshID for legacy stations) |
| 8 |
dword |
RECEIVED |
Number of received packets |
| 12 |
dword |
BYTES |
Number of bytes received from SRC_MAC |
| 16 |
byte |
RSSI |
Current RSSI |
| 17 |
byte |
RX_MCS |
Rate MCS from RX data. The encoding depends on the “RX_MCS type” field of RX_FLAGS and it is defined as follows: In HT mode the MCS is a value in the range 0-15, with bit 3 indicating whether the packet was transmitted in single or double stream MIMO mode. b6-b7: reserved |
| 18 |
byte |
RX_FLAGS |
RX flags for last RX packets to this station bit 0: 40 MHz bit 4-5: RX_MCS type: 0 = no HT, 1 = HT, 2 = VHT, 3=HE bit 6-7: GI (0=0.8uS, 1=0.4uS, 2=1.6uS 3=3.2uS) Note: 5 and 10 MHz channel widths are reported as 20 MHz. Cross-check the Radio Config TLV for the exact channel width used. |
| 19 |
byte |
RESERVED_1 |
Reserved |
| 20 |
word |
AGE |
Milliseconds since last update |
HANDOFF_TBL_MULTI_RADIO TLV (Type: 0x021)
This TLV contains information about currently established connections between mobile and infrastructure units (i.e. connections carrying user traffic). It can be generated by both type of units. Currently, it is sent only by the infrastructure unit that received the handoff request. If it is written by an infrastructure unit, the TLV may contain multiple L3Handoff structures.
This TLV contains information about the primary paths only. If the MPO feature is enabled, handoff information about secondary path IDs (path ID > 0) is sent using TLV ID 0x025 (see below).
Table 37 - Definition of L3Handoff structure
| OFFSET |
TYPE |
VALUE |
DESCRIPTION |
| 0 |
dword |
SBR |
Interface IP of infrastructure unit (stable connection) connected to the vehicle |
| 4 |
dword |
MBR |
Interface IP of mobile unit connected to the infrastructure (stable connection) |
| 8 |
dword |
MASTER |
Mesh ID of mobile master unit |
| 12 |
dword |
VEHICLE_ID |
Remote vehicle ID |
| 16 |
dword |
HO_SEQ |
Handoff sequence number |
| 20 |
dword |
AGE |
Milliseconds since last handoff update |
| 24 |
byte |
RESERVED |
This field is set to zero |
| 25 |
byte |
NUM_UNITS |
Number of secondary on-board units (excluding the master) |
| 26 |
dword[NUM] |
UNITS |
Array of Mesh ID of on-board units |
AGGR_TRAFFIC_MULTI_RADIO TLV (Type: 0x022)
This TLV contains a summary of aggregated traffic flowing through the different interfaces.
It contains a fixed part aggr_eth_traff for aggregated ethernet traffic and a variable number of structures aggr_wlan_traff for aggregated wireless traffic, one for each wireless interface of the device. The number can be calculated as N = (TLV_LEN - sizeof(aggr_eth_traff)) / sizeof(aggr_wlan_traff).
Table 38 - Definition of aggr_eth_traff structure
| OFFSET |
TYPE |
VALUE |
DESCRIPTION |
| 0 |
dword |
RX_LAN |
Kbps |
| 4 |
dword |
TX_LAN |
Kbps |
Table 39 - Definition of aggr_wlan_traff structure
| OFFSET |
TYPE |
VALUE |
DESCRIPTION |
| 0 |
dword |
RX_WLAN |
Kbps |
| 4 |
dword |
TX_WLAN |
Kbps |
| 8 |
dword |
AVAILABLE_CAPACITY |
Available link capacity |
RADIO_CFG_MULTI_RADIO TLV (Type: 0x023)
This TLV provides information regarding the operating parameters of the WLAN interfaces of the device. It contains up to N multi_radio_cfg_tlv structures (one for each physical radio NIC of the device). The definition of the multi_radio_cfg_tlv structure is the following:
Table 23 - Definition of multi_radio_cfg_tlv structure
| OFFSET |
TYPE |
VALUE |
DESCRIPTION |
| 0 |
byte |
DEVINFO |
b0-b1: Radio interface ID (zero-based) b2-b7: Reserved |
| 1 |
byte |
MODE |
b0-b2: Operating mode: 0=unused, 1=Fluidity, 2=Fixed Infrastructure, 3=Fluidmax, 4=Bridge (Intracar) b4: Interface enabled b5: HE enabled (802.11ax) |
| 2 |
byte[6] |
WMAC |
Radio interface MAC address |
| 8 |
byte |
STATUS |
b0-b4: Reserved b5: TDMA or CSMA (TDMA if set) b6: Scanning flag (if set, the radio is currently doing a frequency scan). b7: TX disabled (if set, TX is disabled) |
| 9 |
byte |
TXPWR |
Current TX power, in dBm (signed 8-bit integer) |
| 10 |
word |
CWIDTH |
b0-b11: Current channel width (MHz) (0 if scanning) b12-b15: Reserved |
| 12 |
dword |
FREQ1 |
b0-b16: Current primary operating frequency, (MHz) (0 if scanning) b17-b31: Reserved |
| 16 |
dword |
FREQ2 |
b0-b16: Current secondary operating frequency (MHz) (0 if scanning) b17-b31: Reserved |
Note: when the interface is disabled, the various bit will reflect the current configuration status, although it is not meaningful for the system.
MPO EXT TLV (Type: 0x024)
This TLV contains a variable number of mpoext_state structures. The number can be calculated as N = TLV_LEN / sizeof(urw_client_entry).
The definition of the mpoext_state structure is the following:
Table 30 - Definition of mpoext_state structure
| OFFSET |
TYPE |
VALUE |
DESCRIPTION |
| 0 |
byte[6] |
SRC_MAC |
Client source Mac address |
| 6 |
dword |
TX1 |
Number of transmitted packets accepted in the duplication process and transmitted on the primary path |
| 10 |
dword |
TX2 |
Number of transmitted packets accepted in the duplication process and transmitted on the secondary path (if available) |
| 14 |
dword |
R1_ACCEPTED |
Number of received packets accepted in the de-dup process in the primary path |
| 18 |
dword |
R1_DROP |
Number of received packets accepted in the de-dup process in the primary path but dropped |
| 22 |
dword |
R2_ACCEPTED |
Number of received packets accepted in the de-dup process in the secondary path |
| 26 |
dword |
R2_DROP |
Number of received packets accepted in the de-dup process in the secondary path but dropped |
| 30 |
dword |
LOST |
Number of packets lost both on the primary path and secondary path |
| 34 |
dword |
LOST1 |
Number of packets lost ONLY on the primary path and but received on secondary path |
HANDOFF_TBL_MULTI_RADIO_MPO TLV (Type: 0x025)
This TLV contains information about secondary path connections between mobile and infrastructure units (i.e. connections carrying user traffic). It can be generated by both type of units. Currently it is sent only by the infrastructure unit who received the handoff request. If it is written by an infrastructure unit, the TLV may contain multiple L3Handoff structures.
The information sent consists in all active secondary path ID entries (1-7) for the vehicle which is doing the handoff only.
Table 37 - Definition of L3Handoff structure
| OFFSET |
TYPE |
VALUE |
DESCRIPTION |
| 0 |
dword |
SBR |
Interface IP of infrastructure unit (stable connection) connected to the vehicle (MeshID for legacy stations) |
| 4 |
dword |
MBR |
Interface IP of mobile unit connected to the infrastructure (stable connection) (MeshID for legacy stations) |
| 8 |
dword |
MASTER |
Mesh ID of mobile master unit |
| 12 |
dword |
VEHICLE_ID |
Remote vehicle ID |
| 16 |
dword |
HO_SEQ |
Handoff sequence number |
| 20 |
dword |
AGE |
Milliseconds since last handoff update |
| 24 |
byte |
URW_FLAGS |
b0-b2: Path ID (1-7) b3-b7: Reserved (zero) |
| 25 |
byte |
NUM_UNITS |
Number of on-board units (including the master) |
| 26 |
dword[NUM] |
UNITS |
Array of Mesh ID of on-board units |
BLOCKLIST MULTI-RADIO TLV (Type: 0x026)
This TLV contains a snapshot of the current FHCtrl handoff blacklist content for multi-radio devices such as IW916x. It is transmitted by Fluidity infrastructure and mobile units periodically, using the same time interval as RX and TX statistics.
Note that a link may be blacklisted for more than one reason. In this case, multiple entries for the considered link, one for each reason, will be included in the TLV.
The combination LOCAL_IF = 0.0.0.0, REMOTE_IF = 0.0.0.0 is not allowed.
Table 38 - Definition of multi-radio blacklist structure
| OFFSET |
TYPE |
VALUE |
DESCRIPTION |
| 0 |
dword |
LOCAL_IF |
Local interface IP Note 2: Mesh IDs not allowed in this field |
| 4 |
dword |
REMOTE_IF |
Remote interface IP Note 1: a value of 0.0.0.0 corresponds to all wireless interfaces for the remote unit Note 2: Mesh IDs not allowed in this field |
| 8 |
dword |
EXPIRY |
b24-b31: Reason (currently set to 0x00) b23: Scale (0=milliseconds, 1=seconds) b0-b22: Expiry time from now (ms or seconds) |
Reason codes are defined as follows:
Table 39 - Definition of blacklist reason codes
| CODE |
TYPE |
DESCRIPTION |
| 0 |
UNSPECIFIED |
Not available or generic ban type |
| 1 |
FASTDROP |
Wireless fast-drop feature |
| 2 |
POLEBAN |
Pole-proximity / pole-ban feature |
| 3 |
RSSIBAN |
RSSI ban feature |
| 4 |
HO_FAIL |
Handoff failures ban |
| 5 |
HO_REJ |
Handoff rejected ban |
Examples:
1. Ban a specific wireless link
| Local IP |
Remote IP |
Reason |
Comments |
| 3.0.10.1 |
4.0.10.2 |
0 |
Ban the wireless link between radio slot 1 of device 5.0.10.1 and radio slot 2 of device 5.0.10.2 |
2. Ban remote device 5.0.10.2
| Local IP |
Remote IP |
Reason |
Comments |
| 0.0.0.0 |
3.0.10.2 |
0 |
Ban the wireless links between any radio slot of the local device and radio slot 1 of device 5.0.10.2 |
| 0.0.0.0 |
4.0.10.2 |
0 |
Ban the wireless links between any radio slot of the local device and radio slot 2 of device 5.0.10.2 |
3. Ban the second radio slot of the local device
| Local IP |
Remote IP |
Reason |
Comments |
| 4.0.10.1 |
0.0.0.0 |
0 |
Ban all wireless links between radio slot 2 of local device 5.0.10.1 and any radio slot of any remote device |
GNSS_NMEA TLV (Type: 0x027)
Introduced in UIW release 17.13.1
This TLV contains one or more NMEA 0183 sentence(s), represented by null-terminated ASCII strings in a sequence. The TLV is transmitted as soon as the NMEA string is received from the GNSS serial device.
The following NMEA sentences are supported:
FHCTLV_TITAN, TLV_ETHTPT,TLV_MULTIPATH, TLV_FHCTRL_M_MULTI_RADIO, TLV_TXSTATS_MULTI_RADIO, TLV_RXSTATS_MULTI_RADIO, TLV_HOTABLE_MULTI_RADIO, TLV_AGGRTRAF_MULTI_RADIO, TLV_RADIO_CFG_MULTI_RADIO, TLV_URW_EXT, TLV_HOTABLE_MULTI_RADIO_MPO, TLV_BLOCKLIST_MULTI_RADIO
Table 40 - Definition of GNSS_NMEA TLV
| OFFSET |
TYPE |
VALUE |
DESCRIPTION |
| 0 |
byte [] |
NMEA_STR |
NMEA Sentences |
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
All printed copies and duplicate soft copies of this document are considered uncontrolled. See the current online version for the latest version.
Cisco has more than 200 offices worldwide. Addresses and phone numbers are listed on the Cisco website at www.cisco.com/go/offices.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL:https://www.cisco.com/c/en/us/about/legal/trademarks.html.
Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1721R)
© 2024 Cisco Systems, Inc. All rights reserved.
FeedbackContact Cisco
- Open a Support Case
- (Requires a Cisco Service Contract)