DSDPlus Trying to analyze the Packet Data of P25 in version DSD+ 2.441 (LRRP/Location)

Red_Ice · Jan 4, 2024

thewraith2008 said:
You may find this GitHub useful with regards to MOT LRRP and it's structure.
I believe this should apply to both P25 and DMR.

It should be noted the use of VLQ encoding with some of the fields used in LRRP and probably ARS, TMS, Telemetry DATA packets.
Not decoding this encoding is probably why you are seeing strange values or not been able to determining the next token position in the data stream.

The IPv4 headers (with TCP or UDP protocols) should not be over looked as a source of identifying DATA packet types.
While I can't speak much for P25, the DMR standards say some of these header fields (not used by DMR) are fixed, but I have seen this is not always the case.

Thank you for your contribution, I am traveling today and I have not been able to test the software you indicate.

I think that it is actually very easy when you know the mechanics, that I have been able to certify that they carry GPS data with the SAP (service access point) equal to 1 (reserved), 3 (UDP/IP) and 4 (IP), but of course, it is not just these values, but it is the combination of the SAP, with the DPF (data packet format) and with 3 bytes placed in a certain position, of these 3 bytes there are also several different ones.

Depending on the combination of these three elements we will find the GPS information in a certain place in the data packet, but also, depending on them, there will be packets that do not provide the date/time information of when the GPS information was released from the MS or No speed or azimuth information will appear.

thewraith2008 · Jan 4, 2024

The port value can help ID the service usage. e.g. 4001 = LRRP, 4005 = ARS.
I'm sure these values are fixed for these services.

wildlynx said:
Depending on the combination of these three elements we will find the GPS information in a certain place in the data packet, but also, depending on them, there will be packets that do not provide the date/time information of when the GPS information was released from the MS or No speed or azimuth information will appear.

Once you determine the MOT DATA type (LRRP, ARS, TMS, Telemetry), then you can parse the DATA structure identifying the type (i.e. ImmediateLocationResponse) and tokens (i.e. Circle - 0x51) used for it which includes the grouped elements LAT/LONG and Radius.
Doing this does not rely on using offsets which could change if other token(s) are used.

It would be really nice to have a look at the ADK documents to get a clearer picture on all these services.

mtindor · Jan 4, 2024

thewraith2008 said:
The port value can help ID the service usage. e.g. 4001 = LRRP, 4005 = ARS.
I'm sure these values are fixed for these services.

Once you determine the MOT DATA type (LRRP, ARS, TMS, Telemetry), then you can parse the DATA structure identifying the type (i.e. ImmediateLocationResponse) and tokens (i.e. Circle - 0x51) used for it which includes the grouped elements LAT/LONG and Radius.
Doing this does not rely on using offsets which could change if other token(s) are used.

It would be really nice to have a look at the ADK documents to get a clearer picture on all these services.

Can you [or somebody else] explain to me what ARS is? I see LRRP and ARS references, and rarely TMS references.

I know the LRRP stuff shows lat/long type information. What is contained in ARS / TMS? What type of information? Do you know?

Mike

thewraith2008 · Jan 4, 2024

Have a look at this document (Application Development Kit Overview)

ARS = Automatic Registration Service
TMS= Text Messaging Service
LRRP = Location Request and Response Protocol (or just Location Data by MOT)

mtindor · Jan 4, 2024

thewraith2008 said:
Have a look at this document (Application Development Kit Overview)

ARS = Automatic Registration Service
TMS= Text Messaging Service
LRRP = Location Request and Response Protocol (or just Location Data by MOT)

Thanks. Sounds like the only one interesting to most of us would be LRRP then. I guess text messaging would be interesting, but it's probably encrypted in some way. I know I'm only interested in lat/long stuff. Thanks for the info.

thewraith2008 · Jan 4, 2024

mtindor said:
I guess text messaging would be interesting, but it's probably encrypted in some way.

Yes that would seem likely.
I don't think I've seen TMS been sent so I've never looked into it.

ARS probably only useful to those who like see devices REG/DeREG to a system/site/location.

Red_Ice · Jan 5, 2024

thewraith2008 said:
The port value can help ID the service usage. e.g. 4001 = LRRP, 4005 = ARS.
I'm sure these values are fixed for these services.

Once you determine the MOT DATA type (LRRP, ARS, TMS, Telemetry), then you can parse the DATA structure identifying the type (i.e. ImmediateLocationResponse) and tokens (i.e. Circle - 0x51) used for it which includes the grouped elements LAT/LONG and Radius.
Doing this does not rely on using offsets which could change if other token(s) are used.

It would be really nice to have a look at the ADK documents to get a clearer picture on all these services.

First I want to apologize for not answering sooner due to the time difference, that said, I find the idea of LRRP tracking that you propose very interesting, but I think there are some problems with that approach.

To explain my theory a little I show 4 different cases:

In this one, I first show in green the three elements that I think define the LRRP data and that are indicated in red, in blue all the LRRP information appears and in yellow the IP addresses and ports that match your theory.

In this other data packet, the ARS ports appear in the second IP addresses, although it is not indicated and they do have the same values for the SAP and the DPF but they do not transmit the three bytes of LRRP data indicators.

In the third case we see the same SAP and DPF and ports 4001, with an LRRP indication, but it does not include that data, making it difficult to follow that theory.

In the last case, we see that the SAP and the DPF change and that the three bytes are the same, in this case it does not bring IP information or the LRRP indication although it does bring the GPS data except for azimuth in the first packet and that the three bytes are different in the second of them, omitting the date/time.

Therefore, I think it is more feasible to know the SAP, DPF data and the three bytes to know this information, but I am not closed to other ideas like yours about the ports.

Red_Ice · Jan 5, 2024

The previous comment was referring to the DMR, but if we talk about the P25 the study changes in relation to the data provided by the FL. In green I show the SAP, the three bytes and the UID although it does not coincide with the host of the yellow IP addresses, ports 4001 are also shown in yellow which, in this case, does carry that LRRP information, but without showing speed and azimuth.

mtindor · Jan 5, 2024

In case you all don't know, TIII CAPMAX systems (and maybe all TIII systems) are capable of having/using a dedicated data channel. I was monitoring a dedicated data channel for a local TIII CAPMAX site today and found some LRRP on it. Neither DSDPlus or SDRTrunk knew it was LRRP, but I found it based upon the 31AF.

As you'll see below, the date/time appear to be off a little, but that is of no surprise to me. lat/long are accurate. I don't know what all the other gibberish is.

Code:

SDRTRUNK:  20240105 084527,PASSED,CC:0 FM:106 TO:13 IP FROM:12.0.0.106 TO:13.0.0.13 UDP PORT FROM:4001 TO:30000 UNKNOWN PACKET:0D252203000001341FA0491E4C55396EA3F7C6BAB5B0407C815C144A5B6C0067566970404C653C000857165F
1FA0491E4C = 0001111110100000010010010001111001001100

DSDPLUS:  2024.01.05  8:45:28  Raw data: 45 00 00 43 D6 8F 00 00 40 11 8A A4 0C 00 00 6A 0D 00 00 0D 0F A1 75 30 00 2F A1 01 0D 25 22 03 00 00 01 34 1F A0 49 1E 4C 55 39 6E A3 F7 C6 BA B5 B0 40 7C 81 5C 14 4A 5B 6C 00 67 56 69 70 40 4C 65 3C 00 08 57 16 5F
1F A0 49 1E 4C = 0001111110100000010010010001111001001100

000 11111101000 | 0001 | 00100 | 10001 | 111001 | 001100
    2024          JAN    4       17      41       8
 
396EA3F7 C6BAB5B0 407C815C144A5B6C0067566970404C653C000857165F
396EA3F7 = 963,552,247
(963552247 * 180) / 4,294,967,295 = 40.38200

C6BAB5B0 = 3,334,124,976
((3334124976 * 360) / 4,294,967,295) - 180 = -80.53687

40.38200,-80.53687 = https://maps.app.goo.gl/5zV7VCsgetDvfeqV8

thewraith2008 · Jan 5, 2024

wildlynx said:
In this other data packet, the ARS ports appear in the second IP addresses, although it is not indicated and they do have the same values for the SAP and the DPF but they do not transmit the three bytes of LRRP data indicators.

If it's a ARS packet, then it's structure is not same as Location DATA packet so the header bytes ('LRRP indicators' or 'Marker') will be different

The 3 bytes (e.g. 0x0D0A22) you are calling 'LRRP indicators' or 'Markers' break down as follows:

Packet type = 0x0D 'TriggeredLocationData'
Length = 0x1A (26 bytes (start at 0) - from byte following this byte to the terminating token 0x00)
? = 0x22 ?

These values are most likely different for each MOT service (LRRP, ARS, TMS, Telemetry)

wildlynx said:
In the third case we see the same SAP and DPF and ports 4001, with an LRRP indication, but it does not include that data, making it difficult to follow that theory.

Is this even a MOT Location DATA service packet?
Other MFGs data packets that carry location data will be structured differently. (after any IPv4 and TCP/UDP headers)

The DPF and the SAP only serve to indicate how the data is transported via the radio system and not what the usage/content of the DATA is.

DPF tells us that each data packet was confirmed or unconfirmed or a proprietary type.
SAP indicates the transport protocols like IPv4 TCP/UDP or a proprietary transport layer

I believe the GitHub provided in post early provides a good insight to these MOT services.
It's not a complete breakdown of the structure but provides a good start.

mtindor · Jan 5, 2024

mtindor said:
In case you all don't know, TIII CAPMAX systems (and maybe all TIII systems) are capable of having/using a dedicated data channel. I was monitoring a dedicated data channel for a local TIII CAPMAX site today and found some LRRP on it. Neither DSDPlus or SDRTrunk knew it was LRRP, but I found it based upon the 31AF.

As you'll see below, the date/time appear to be off a little, but that is of no surprise to me. lat/long are accurate. I don't know what all the other gibberish is.

Code:

SDRTRUNK: 20240105 084527,PASSED,CC:0 FM:106 TO:13 IP FROM:12.0.0.106 TO:13.0.0.13 UDP PORT FROM:4001 TO:30000 UNKNOWN PACKET:0D252203000001341FA0491E4C55396EA3F7C6BAB5B0407C815C144A5B6C0067566970404C653C000857165F 1FA0491E4C = 0001111110100000010010010001111001001100 DSDPLUS: 2024.01.05 8:45:28 Raw data: 45 00 00 43 D6 8F 00 00 40 11 8A A4 0C 00 00 6A 0D 00 00 0D 0F A1 75 30 00 2F A1 01 0D 25 22 03 00 00 01 34 1F A0 49 1E 4C 55 39 6E A3 F7 C6 BA B5 B0 40 7C 81 5C 14 4A 5B 6C 00 67 56 69 70 40 4C 65 3C 00 08 57 16 5F 1F A0 49 1E 4C = 0001111110100000010010010001111001001100 000 11111101000 | 0001 | 00100 | 10001 | 111001 | 001100 2024 JAN 4 17 41 8 396EA3F7 C6BAB5B0 407C815C144A5B6C0067566970404C653C000857165F 396EA3F7 = 963,552,247 (963552247 * 180) / 4,294,967,295 = 40.38200 C6BAB5B0 = 3,334,124,976 ((3334124976 * 360) / 4,294,967,295) - 180 = -80.53687 40.38200,-80.53687 = https://maps.app.goo.gl/5zV7VCsgetDvfeqV8

The previous post of mine was for RadioID 106 of the radio shop. Looks like RadioID 107 is also sending something, but I'm guessing it is ARS because it's a much shorter bit of data and doesn't seem to contain any lat/long stuff.

Code:

SDRTRUNK:  20240105 085116,PASSED,CC:0 FM:107 TO:13 IP FROM:12.0.0.107 TO:13.0.0.13 UDP PORT FROM:4001 TO:30000 UNKNOWN PACKET:0D072203000001371000000000000000D025925D

DSDPLUS:  2024.01.05  8:51:16  Raw data: 45 00 00 25 6C FD 00 00 40 11 F4 53 0C 00 00 6B 0D 00 00 0D 0F A1 75 30 00 11 21 42 0D 07 22 03 00 00 01 37 10 00 00 00 00 00 00 00 D0 25 92 5D

Red_Ice · Jan 5, 2024

As you can see in the image, I mark three bytes that are the LRRP data indicative and then 2 more bytes, perhaps for those who are not yet very familiar with this data the latter is the interesting one, 34 is the byte that precedes the date and on the other hand, 1F would be the start byte of this year and several more years before moving on to byte 20.

Prior to this is the source/destination IP address and the source/destination ports.

thewraith2008 · Jan 5, 2024

mtindor said:
In case you all don't know, TIII CAPMAX systems (and maybe all TIII systems) are capable of having/using a dedicated data channel. I was monitoring a dedicated data channel for a local TIII CAPMAX site today and found some LRRP on it. Neither DSDPlus or SDRTrunk knew it was LRRP, but I found it based upon the 31AF.

As you'll see below, the date/time appear to be off a little, but that is of no surprise to me. lat/long are accurate. I don't know what all the other gibberish is.

Code:

SDRTRUNK: 20240105 084527,PASSED,CC:0 FM:106 TO:13 IP FROM:12.0.0.106 TO:13.0.0.13 UDP PORT FROM:4001 TO:30000 UNKNOWN PACKET:0D252203000001341FA0491E4C55396EA3F7C6BAB5B0407C815C144A5B6C0067566970404C653C000857165F DSDPLUS: 2024.01.05 8:45:28 Raw data: 45 00 00 43 D6 8F 00 00 40 11 8A A4 0C 00 00 6A 0D 00 00 0D 0F A1 75 30 00 2F A1 01 0D 25 22 03 00 00 01 34 1F A0 49 1E 4C 55 39 6E A3 F7 C6 BA B5 B0 40 7C 81 5C 14 4A 5B 6C 00 67 56 69 70 40 4C 65 3C 00 08 57 16 5F

This is probably a good example of why using fix offsets doesn't work in the long run.
This has the header of 0x0D2522, more elements and has probably pushed the expected element further along.

Red_Ice · Jan 5, 2024

thewraith2008 said:
If it's a ARS packet, then it's structure is not same as Location DATA packet so the header bytes ('LRRP indicators' or 'Marker') will be different

The 3 bytes (e.g. 0x0D0A22) you are calling 'LRRP indicators' or 'Markers' break down as follows:

Packet type = 0x0D 'TriggeredLocationData'

Length = 0x1A (26 bytes (start at 0) - from byte following this byte to the terminating token 0x00)

? = 0x22 ?

These values are most likely different for each MOT service (LRRP, ARS, TMS, Telemetry)

Is this even a MOT Location DATA service packet?
Other MFGs data packets that carry location data will be structured differently. (after any IPv4 and TCP/UDP headers)

The DPF and the SAP only serve to indicate how the data is transported via the radio system and not what the usage/content of the DATA is.

DPF tells us that each data packet was confirmed or unconfirmed or a proprietary type.

SAP indicates the transport protocols like IPv4 TCP/UDP or a proprietary transport layer

I believe the GitHub provided in post early provides a good insight to these MOT services.
It's not a complete breakdown of the structure but provides a good start.

Thanks for the contribution, I knew this data, but I recognize that it is very interesting to expose it so that others can see it.

In this example and only for the combination 0D1A22 something special happens:

0x1A = 26, half is 13, in byte 13 from these the latitude begins.
0x22 = 34, half is 17, in byte 17 from these the length begins.

thewraith2008 · Jan 5, 2024

wildlynx said:
Thanks for the contribution, I knew this data, but I recognize that it is very interesting to expose it so that others can see it.

In this example and only for the combination 0D1A22 something special happens:

0x1A = 26, half is 13, in byte 13 from these the latitude begins.
0x22 = 34, half is 17, in byte 17 from these the length begins.

Following these header bytes is another length byte which is used for a requestID
I've seen like 0x03-000001
After this is where the tokens with grouped elements and values if applicable begins. This is where you find tokens like: 0x34, 0x66, 0x69, 0x6C, 0x56 etc...

NOTE: Same token numbers may mean something different with different packet types.

thewraith2008 · Jan 5, 2024

mtindor said:
The previous post of mine was for RadioID 106 of the radio shop. Looks like RadioID 107 is also sending something, but I'm guessing it is ARS because it's a much shorter bit of data and doesn't seem to contain any lat/long stuff.

Code:

SDRTRUNK: 20240105 085116,PASSED,CC:0 FM:107 TO:13 IP FROM:12.0.0.107 TO:13.0.0.13 UDP PORT FROM:4001 TO:30000 UNKNOWN PACKET:0D072203000001371000000000000000D025925D DSDPLUS: 2024.01.05 8:51:16 Raw data: 45 00 00 25 6C FD 00 00 40 11 F4 53 0C 00 00 6B 0D 00 00 0D 0F A1 75 30 00 11 21 42 0D 07 22 03 00 00 01 37 10 00 00 00 00 00 00 00 D0 25 92 5D

I think this is a LRRP response code. (Token:0x37 Response Code: 0x10 - NoGPS)

Red_Ice · Jan 5, 2024

It really strikes me that the latitude and longitude token (byte) is the only one that changes, but I don't know the reason, the other three are always the same.

thewraith2008 · Jan 5, 2024

wildlynx said:
It really strikes me that the latitude and longitude token (byte) is the only one that changes, but I don't know the reason, the other three are always the same.

It's because LAT/LONG can be grouped with other elements.
These different groupings have different tokens (names: Circle, Sphere etc).

Red_Ice · Jan 5, 2024

I understand then that depending on whether the date/time or the speed or the azimuth appears, it will have a different token?

thewraith2008 · Jan 5, 2024

wildlynx said:
I understand then that depending on whether the date/time or the speed or the azimuth appears, it will have a different token?

Sorry for the rough copy/paste but hope this help explain grouping that can use same elements (like LAT/LONG)

Code:

                   case 0x51: //Circle 
                        this.latitude
                        this.longitude
                        this.radius
                    case 0x55: //Sphere
                        this.latitude
                        this.longitude
                        this.radius
                        this.altitude
                        this.altitueAccuracy
                    case 0x56:
                        this.horizontalDirection
                    case 0x66:
                        this.latitude
                        this.longitude
                    case 0x69:
                        this.latitude
                        this.longitude
                        this.altitude

Not all the groupings names are known.

DSDPlus Trying to analyze the Packet Data of P25 in version DSD+ 2.441 (LRRP/Location)

Member

Member

OH/WV DB Admin

Member

OH/WV DB Admin

Member

Member

Member

OH/WV DB Admin

Member

OH/WV DB Admin

Member

Member

Member

Member

Member

Member

Member

Member

Member

Similar threads