Understanding Capacity Plus trunking, some more

[thewraith2008]

Just heading out for a few hours, so I can't go into much detail now.

The CRC-3 polynomial may be 0x03 or 0x06 (see CRC-3-GSM).

The EMB service options (the 2 reserved bits) do indicate:

• The next EMB RC field is used (for whatever they use it for) in frame F (of current superframe). - BAD CRC is seen.
• The voice payload field of frame F is used (for whatever they use it for) of next superframe. - 'RRR' is seen after the 3 voice frames are passed through the MBE decoding process.

 

[lwvmobile]

The CRC-3 polynomial may be 0x03 or 0x06 (see CRC-3-GSM).

That was the same one I stumbled across earlier. I've got the crc working now, I was just feeding it the wrong bits to check against, since the 3-bit CRC is the 3 MSB when received, I forgot to shift it to check the last 8 bits and not the first 8 bits.

Also, now that I have that straigtened out, what I believed to be the Cap+ Site ID is not a consistent value, so pretty sure that was just a red-herring since there is so few bits, its easy to find patterns out of unrelated information. The information and opcode is consistently the Delay Opcode and delay value.

 

[thewraith2008]

OK, I have added the CRC-3 as well and seems to be passing the check on the Embedded RC when it presence is indicated.

On some CAP+, I seem to be getting indication of interrupt "Superframe 3 burst E (60mS)".
It's just two people talking as normal.
Also see: "Irrelevent, send anytime" on another CAP+.
I wonder if it has some other meaning than what the patent states.

This is a bit of an obscure find, well done.
These patents are a bit of a dry read. "It will be appreciated by those of ordinary skill in the art..."

 

[lwvmobile]

On some CAP+, I seem to be getting indication of interrupt "Superframe 3 burst E (60mS)".
It's just two people talking as normal.
Also see: "Irrelevent, send anytime" on another CAP+.
I wonder if it has some other meaning than what the patent states.

Yeah, I seem to get the 0x313, or 60ms Delay on most systems, with one exception that seems to bounce between 0x643 and 0x203. I figure there is a chance there are more ways to read it, the patent was from back in 2012 or so, so it could have changed meanings. No idea. Honestly, the only reason I wanted to have that handling is so I could know when to look for the late entry key/alg on enc and it accidentally set bad enc identifiers off the TXI stuff.

"It will be appreciated by those of ordinary skill in the art..."

It makes me want to slap somebody every time I read that. I can appreciate they are short on bits there, but I don't appreciate the lack of CRC on encryption data in the single burst. Just seems like a bad idea. Also shows how little foresight they had when developing DMR that they didn't think having adequate space/handling for continuous ENC information would be necessary.

Also, forgot to meniton. I think, what my thoughts are worth anyways, is that the BR Delay is when the radio who wants to broadcast an interrupt will be able to do so, and not that it is going to do so. Also, what I'm thinking now is that the pre-empted VC6 is pre-empted regardless of any interruption, that's just the window the current talker allots to not broadcast and allow another radio to use the interrupt RC channel, and instead of playing dead air on the repeater, the repeater just puts out 3 duplicate repeat frames. I'm guessing the CSBK it mentions for interrupt request is only played inbound by another radio when required, and not on the outbound repeater.

 

[thewraith2008]

At least there is the the Quadratic Residue on the EMB field, so it's not completely without FEC, but I get what what you are saying.
Better to have the extra CRC for something more important like the KeyID field when used (opcode=1).
Makes me wonder if opcodes: 2,4,5,6,7 are for other encryption types.

They seem to be frame stealing when it's not needed.
I've seen some shocking frame steals on TETRA sometimes.
Seems odd to me, isn't the voice the more important part? DMR needs less voice frames like a hole in the head.

 

[lwvmobile]

Yeah, I forgotten about the QR, probably because if its not good, then I usually break sync and wait for the next set of voice frames to start.

Makes me wonder if opcodes: 2,4,5,6,7 are for other encryption types.

Yes. Yes they are, at least for the algs that are known to me. Here are a few simplex samples I've gathered with known information. Usually the same holds true on BS as well. Very seldomly does it not.

AES-256 (algid 0x25 or 0x05) - Key 4;
SB: 00000100101 - 025;

AES-128 (algid 0x24 or 0x04) - Key 3;
SB: 00000011100 - 01C;

DES1 (0x22 or 0x02) - Key 1
SB: 00000001010 - 00A;
Slot 1 DMR LE SB ALG ID: 22 KEY ID: 1
Slot 1 PI/LFSR and Late Entry MI Mismatch - 00000000 : 47B90290
Slot 1 DMR PI C- ALG ID: 0x22 KEY ID: 0x01 MI: 0x47B90290EF99DAE5
 
RC4 (0x21 or 0x01) - Key 2
SB: 00000010001 - 011;
 Slot 1 DMR LE SB ALG ID: 21 KEY ID: 2
 Slot 1 DMR PI C- ALG ID: 0x21 KEY ID: 0x02 MI: 0x00000000
 Slot 1 PI/LFSR and Late Entry MI Mismatch - 00000000 : 1BDBCBC8
 
Anytone RC4 (0x1) - Key 0x67
SB: 01100111001 - 339;
Slot 1 DMR LE SB ALG ID: 21 KEY ID: 67
Slot 1 DMR PI C- ALG ID: 0x21 KEY ID: 0x67 MI: 0x00000000
Slot 1 PI/LFSR and Late Entry MI Mismatch - 00000000 : B468E067

Clear
SB: 00000000000 - 000;

They seem to be frame stealing when it's not needed.
I've seen some shocking frame steals on TETRA sometimes.
Seems odd to me, isn't the voice the more important part? DMR needs less voice frames like a hole in the head.

I've seen NXDN48 be the most shocking culprit of this behavior, it will steal voice frames for facch1 frames, just to send an IDLE message in the facch1 steal. Ideally, its good for VCALL_ASSGN_DUP which is a grant update on another voice channel, but the facch1 steal IDLE message just baffles me. At least with just one random voice steal, its not very noticeable. I've also noticed a similar behavior on Retevis TDMA Direct Mode, or DCDM, where every single AMBE3 frame has the same errors or repeat frame, like its using that area to send hidden data.I never could determine if its just a crappy radio, or if the bad ambe frame was by design and its sending a data packet or something, or doing that to allow the DCDM mode to work somehow.

 

[thewraith2008]

So from those examples, it looks like the Key ID is in the first 8 bits and not first 3 (CRC) as the patent describes.

For example, when used to transport encryption parameters, a 3-bit Key ID occupies those 3 bits. The CRC is present when Opcode=BR
Delay (011) and Opcode=Null (000), but NOT when Opcode=ARC4 (001).

No shock there I guess that the patent and the real world usage don't match.

 

[thewraith2008]

At least there is the the Quadratic Residue on the EMB field, so it's not completely without FEC

While that is true, what I meant was the EMB signalling DATA field (32 bits) is "protected" by the vBPTC (16,11 hamming).
Any who.


With the last two you listed:

RC4 (0x21 or 0x01) - Key 2
Anytone RC4 (0x1) - Key 0x67

How do you differentiate between the two (Anytone RC4 and RC4) when they are both opcode=1?

 

[lwvmobile]

How do you differentiate between the two (Anytone RC4 and RC4) when they are both opcode=1?

To be honest, it really doesn't matter, both work the same way. Its just an interesting tidbit that in the PI header, for whatever reason, the first byte that indicates the ALG ID is 0x21, 0x22, 0x24, 0x25 for RC4, DES, AES-128, and AES-256 unless its not DMRA or Moto (really unsure) then it'll just be 0x01 for RC4 (Anytone) , 0x05 for AES-256 (Anytone and Hytera, I think), etc. Not sure why, maybe the ALG IDs only relevant bits are the 3 LSB on that byte, while the rest of the bits signify something else, but the usually players (last block and protect flag) don't flip the bit in the 0x20 position. To be honest, I can't imagine why they need to have the space for up to 255 different ALG IDs, maybe they are trying to catch up to all the oddball ALGs that P25 can potentially support. Its also not covered by the ETSI manuals, so manufacturers are free to do whatever they want to with the PI header anyways.

 

[lwvmobile]

Well, I think I found one chink in the armor, unless my CRC3 calculation is slightly off, but a combination of AES-256 and Key 1 will have a correct CRC3, at least it does on the random Anytone AES-256 sample I got recently.

 SB: 00000001101 - 00D;
 Slot 1 DMR PI C- ALG ID: 0x05 KEY ID: 0x01 MI: 0xA49A640267633CC9

Another thing I wonder, if anybody out there knows, is if in DMR, is Triple DES, or any other DES combo a valid ALG for DMR? I know the single DES key is 0x22 or 0x02, but I was wondering if what might have been alg 0x23 or 0x03 is Double or Triple DES, or nothing/undefined? Anybody know if you can program Double or Triple DES into DMR? If not and the 0x03 algid is unused, then maybe that's why it was chosen for TXI.

Since the above example (seemingly) passes the CRC3, I wonder if using the CRC3 as the method to gauge when to set the alg and key is the correct procedure, or if we just want to avoid opcode 3 for TXI and everything else is valid alg/key combos.

 

[thewraith2008]

I wonder if using the CRC3 as the method to gauge when to set the alg and key is the correct procedure, or if we just want to avoid opcode 3 for TXI and everything else is valid alg/key combos.

The patent did say the CRC is present when:

• Opcode=BR Delay (011) and Opcode=Null (000)
• but NOT when Opcode=ARC4 (001) and presumably 2, 4, 5, 6, 7.

So only check the CRC when opcode=3.

I don't think there are to many unique CRCs with CRC-3.

If you did check the CRC when opcode != 3, then here are what values are seen with a CRC3=0 and the opcode=5

 1 [0x01] - 000-00001-101 - CRC3=0 [0x0]
12 [0x0C] - 000-01100-101 - CRC3=0 [0x0]
22 [0x16] - 000-10110-101 - CRC3=0 [0x0]
27 [0x1B] - 000-11011-101 - CRC3=0 [0x0]

NOTE: Hope my implementation of CRC-3 is right