P25 Control Channel decoding

[mobile_1]

I though this could be the place to ask Jay911 all those really tough APCO P25 packet data questions. Please have a look these. Thanks

[MikeOxlong]

Mobile_1, I moved your topic to the Trunked Control Channel Decoding forum so more than just Jay911 can help out.

The authors of the various P25 control channel decoding programs hang out here so your questions will be viewed by the experts.

[Jay911]

Hi mobile_1, here's what I've got.

On group voice calls (opcode 00, or opcode 80 in your case since the system is declaring "last block" on everything apparently), the third octet is Service Options.

Bit 7 (leftmost), when active, means Emergency.
Bit 6 means Protected (encrypted).
Bit 5 if 0 is half duplex (either transmit or receive only) and if 1 is full duplex (can xmit and receive simultaneously).
Bit 4 if 0 is circuit mode, 1 is packet mode. Indicates two different modes of carrying the traffic. I'm not up to speed on the differences.
Bit 3 is, according to the standards, supposed to be null/zero.
Bits 2 thru 0 is the priority. Transmissions can have a priority from 0 to 7. '4' is the default priority. In my copy of the standards, priority 0 is supposed to be 'reserved', but apparently M/A-COM considers it valid if you're receiving calls with it set.

On the unknown codes from site 149 -

Opcode A0 is really opcode 20, Acknowledge Response FNE (Fixed Network Equipment).
Thus the third octet is Service Type with the first two bits being a little complicated. Bit 7 is AIV (Additional Information Valid) and Bit 6 is EX (Extended data).

"The AIV and EX flags determine the interpretation of the Additional Information in octets 3-6." In every one of your sample TSBKs though, octets 3-6 are blank. Octets 7-9 are the radio ID, and of course octets 10-11 are the CRC.

Hex 29 = binary 00101001. This means that AIV is 0 and EX is 0. This in turn means that there will be no useful data in octets 3-6. The rest, 101001, is the Service Type, which is "set equal to the appropriate opcode value for the identified service".

Now here I'm stabbing in the dark so I could be way off the mark. ISP opcode 29 is Group Affiliation Query Response; it's possible that the system, when accepting the Unit Registration Command, is sending a Group Affiliation Query. Thus it would send opcode 20 (A0), Acknowledge Response FNE, saying "yeah, I got you affiliating with me", and within opcode 20, sends opcode 29 back, meaning "and what group are you listening to?".

Perhaps that's considered a more efficient way of doing things than acknowledging the affiliation with a "blank" Ack FNE, and then sending an opcode 2A (Group Affiliation Query), taking up another TSBK (or two if extended).

Also, FYI - you list 16777213 as the "dispatch console" RID. Not exactly accurate - FFFFFD (16777213) is defined as "system default" with a description of "used for messages addressed to or from the FNE call processing function including operations as registration/mobility". There are a few other default reserved RIDs:

16777212 = FNE (Fixed Network Equipment) - "used for messages addressed to or from the FNE radio control/dispatch operator function".
16777214 = Registration Default - "the special address for a registration transaction prior to the subscriber unit receiving a valid unit address"
16777215 = All Units - "identifies all subscriber units"
0 = No Units - "a placeholder for the subscriber unit address/identifies no specific unit"

Valid RIDs for individual units, therefore, range from 1 to 16777211.

[MikeOxlong]

Originally Posted by Jay911

Bit 4 if 0 is circuit mode, 1 is packet mode. Indicates two different modes of carrying the traffic. I'm not up to speed on the differences.

If its the same as the cellular world, circuit switched is for voice calls and packet switched is for data calls.

[mobile_1]

Originally Posted by Jay911

Hi mobile_1, here's what I've got.

On group voice calls (opcode 00, or opcode 80 in your case since the system is declaring "last block" on everything apparently), the third octet is Service Options.

Bit 7 (leftmost), when active, means Emergency.
Bit 6 means Protected (encrypted).
Bit 5 if 0 is half duplex (either transmit or receive only) and if 1 is full duplex (can xmit and receive simultaneously).
Bit 4 if 0 is circuit mode, 1 is packet mode. Indicates two different modes of carrying the traffic. I'm not up to speed on the differences.
Bit 3 is, according to the standards, supposed to be null/zero.
Bits 2 thru 0 is the priority. Transmissions can have a priority from 0 to 7. '4' is the default priority. In my copy of the standards, priority 0 is supposed to be 'reserved', but apparently M/A-COM considers it valid if you're receiving calls with it set.

On the unknown codes from site 149 -

Opcode A0 is really opcode 20, Acknowledge Response FNE (Fixed Network Equipment).
Thus the third octet is Service Type with the first two bits being a little complicated. Bit 7 is AIV (Additional Information Valid) and Bit 6 is EX (Extended data).

"The AIV and EX flags determine the interpretation of the Additional Information in octets 3-6." In every one of your sample TSBKs though, octets 3-6 are blank. Octets 7-9 are the radio ID, and of course octets 10-11 are the CRC.

Hex 29 = binary 00101001. This means that AIV is 0 and EX is 0. This in turn means that there will be no useful data in octets 3-6. The rest, 101001, is the Service Type, which is "set equal to the appropriate opcode value for the identified service".

Now here I'm stabbing in the dark so I could be way off the mark. ISP opcode 29 is Group Affiliation Query Response; it's possible that the system, when accepting the Unit Registration Command, is sending a Group Affiliation Query. Thus it would send opcode 20 (A0), Acknowledge Response FNE, saying "yeah, I got you affiliating with me", and within opcode 20, sends opcode 29 back, meaning "and what group are you listening to?".

Perhaps that's considered a more efficient way of doing things than acknowledging the affiliation with a "blank" Ack FNE, and then sending an opcode 2A (Group Affiliation Query), taking up another TSBK (or two if extended).

Also, FYI - you list 16777213 as the "dispatch console" RID. Not exactly accurate - FFFFFD (16777213) is defined as "system default" with a description of "used for messages addressed to or from the FNE call processing function including operations as registration/mobility". There are a few other default reserved RIDs:

16777212 = FNE (Fixed Network Equipment) - "used for messages addressed to or from the FNE radio control/dispatch operator function".
16777214 = Registration Default - "the special address for a registration transaction prior to the subscriber unit receiving a valid unit address"
16777215 = All Units - "identifies all subscriber units"
0 = No Units - "a placeholder for the subscriber unit address/identifies no specific unit"

Valid RIDs for individual units, therefore, range from 1 to 16777211.

Jay. Thank you very much for your help with these. The things I noticed about the RIDs from site 149. No Talkgroup associated to them ever. 16777213 is only ever seen associated to MA-Com SUs and never to the Motorola radios that are on PPSTN. Data and status update messages are sent and received only by MA-Com's equipment.
Thanks again!

[mobile_1]

Originally Posted by mobile_1

I though this could be the place to ask Jay911 all those really tough APCO P25 packet data questions. Please have a look these. Thanks

I had another look at these. See what you think now.

[Jay911]

Octet 0 being AD is opcode 2D (plus Last Block indicator, irrelevant to the opcode) = Unit Registration Command. System is demanding to know who radios 185092, 175876, 211204 are. You're saying those radio IDs are invalid ... well, the site is saying essentially the same thing. At some point it's seen some kind of transmission from those radios, and is repeatedly answering back with "Hold on, drop everything, who are you really?" It would appear that the radios are responding with their same radio IDs, as the system is responding with the opcode A0 (20 with Last Block), saying "Yes, I acknowledge you say you're 211204."

Context is often important in this sort of thing, so seeing a dump log with none of the other TSBKs stripped out would be useful.

Opcode 20 Acknowledge Response FNE, according to the standards, does not make reference to the LCNs of any frequencies; if you're seeing such, it's just a coincidence.

In a TSBK where you have Opcode 20, octet 2 (the third one) is important in determining the data carried in the rest of the octet. Convert octet 2 from hex to binary and determine what the leftmost two bits are. (Sorry if this is repeating what I posted previously, it possibly is).

Leftmost bit: 1 means "Additional Information Valid". If AIV is true (1), then pay attention to the following bit.
Second-leftmost bit: Extended Information flag. If EX is 1, octets 3-6 contain WACN and System ID. If EX is 0, octet 3 is ignored, and 4-6 contain a Source Address (radio ID).

On the other hand, if AIV = 0, octets 3-6 are irrelevant (null, empty, ignored, however you wish to put it).

As stated above, the remaining six bits are the Service Type.

Octets 7-9 in ACK_RSP_FNE are always Target Address/ID, "the normally assigned address of a target SU" (SU = Subscriber Unit, aka radio).

Looking over my previous message, I say:

Now here I'm stabbing in the dark so I could be way off the mark. ISP opcode 29 is Group Affiliation Query Response; it's possible that the system, when accepting the Unit Registration Command, is sending a Group Affiliation Query. Thus it would send opcode 20 (A0), Acknowledge Response FNE, saying "yeah, I got you affiliating with me", and within opcode 20, sends opcode 29 back, meaning "and what group are you listening to?"

I think I was getting it backwards. Opcode 20 says "I acknowledge you"; Service Type 29 in a TSBK with Opcode 20 is saying "I acknowledge you responding to a Group Affiliation Query". It's not a further demand, it's telling the SU (radio) what it's acknowledging.

So yes, if the PRO96COM author were to view this info and agree with my analysis, perhaps "Unknown code 0x29" wouldn't be unknown any more.

[mikey60]

Sounds right to me...

Mike

[mobile_1]

I need to get the dump to see the whole message. It's not all there for us to understand. Ok thank's again for your help with this.

[mobile_1]

Could you have a look at the unknown packets in the zip file and tell me what they may be. Thanks.

[Jay911]

ISP A3 (23) = Cancel Service Request.
Octet 2 = 90 (10010000 bin); means two things. One, the last six bits (010000) mean the service request being canceled is Individual Data Service Request - "request to initiate a data operation with some network device or other radio unit". The first two bits (10) means octets 4 thru 6, in this case since the last six bits refer to an Individual request, are the address (radio ID) of the "other member of the call".
Octet 3 = 20 = "Terminate Resource Assignment".

Basically: "Cancel that request for me (octets 7-9) to talk to other radio (octets 4-6) for data purposes".

[mikey60]

It's a "Cancel Service Request". Type: "terminate resource assignment"

Some are Radio to Radio, some are Radio to System.

Mike

[mobile_1]

Data grants (txtmsgs) payload captured on voice channels.

[mobile_1]

Originally Posted by mobile_1

Data grants (txtmsgs) payload captured on voice channels.

I was taking a closer look at these data grants on the voice channels .

[Jay911]

I fear you're considerably off the mark here. You're trying to apply trunking control channel data structure info (and a program which analyzes control channel data) to data structures coming from a subscriber unit. I would suspect that the packet format is more in line with the P25 Common Air Interface format. I haven't done any real analysis of the CAI packet structures because my interest is more in control channel data. There is a Response Packet which would match "opcode 03" (octet 0 would be %00000011). "It is used to confirm delivery for data packets sent with the A/N bit set, as shown in the Confirmed Data Packet format (another packet listed in the CAI documentation)."

[mobile_1]

Originally Posted by Jay911

I fear you're considerably off the mark here. You're trying to apply trunking control channel data structure info (and a program which analyzes control channel data) to data structures coming from a subscriber unit. I would suspect that the packet format is more in line with the P25 Common Air Interface format. I haven't done any real analysis of the CAI packet structures because my interest is more in control channel data. There is a Response Packet which would match "opcode 03" (octet 0 would be %00000011). "It is used to confirm delivery for data packets sent with the A/N bit set, as shown in the Confirmed Data Packet format (another packet listed in the CAI documentation)."

Ok Jay, Thanks for the link to the help. I won't post any more of these packets. Thanks again for all your help.