Understanding Connect Plus trunking

[Forts]

Build 48 is now showing the correct Site ID on Connect Plus systems. Anyone that logs various systems (like I do) may want to double check their findings with this new version. As I mentioned earlier, previous versions wouldn't properly recognize a Site ID above 7.

Thanks for rolling this out so quick Ian. I had some great reception coming in last night and logged 17 Connect Plus channels from over the Detroit way (approx 200kms from my location). I'll take another spin thru the dial tonight with the newest version.

 

[mtindor]

Does anyone have an older build (Pre-42) of DMR Decode handy they could send me? I don't believe the current version is properly displaying the Site ID on Connect Plus systems (actually only site ID's over 7 would be incorrect). When we originally sorted out the SLCO=10 packets last year Connect Plus systems had a max of 6 sites, so we focused on the 3 bits displaying the Site ID. Connect Plus now supports 35 sites, meaning we need at least 6 bits to properly display 35 (100011). It should be as simple as widening the the area that DMR Decode is currently looking at for the Site ID. This recently came to my attention as I was seeing some sites logging as Site 0, which is not a valid ID. Then it dawned on me that as it stands now any thing over a value of 7 (111) would likely show up as 0. With an older build of DMRDecode that shows the SLCO=10 packets I would be able to confirm this.

I knew about this phenomenon (strangeness with site IDs) for many months now. I thought it was just our local ConnectPlus system (12-16 sites and growing). I kept arguing with the guy who set it up that his sites are broadcasting a Site ID of ##, when he'd claim they were definitely configured to be ##. I never gave it a thought that it was a problem with DMRDecode. I figured that maybe Site IDs broadcasted didn't have to be "correct" for the system to work and that the operators probably did this intentionally.

At any rate, with build 48, DMRDecode is working like a champ reporting the corrrect site IDs across the board now.

Sorry I didn't bother to bring this problem up sooner than you did. I didn't know the cause, but it's apparent that had I posted about it months ago you guys would have figured out the problem and there would have been a fix much sooner.

I'm not too bright sometimes.

Thanks, Ian, for fixing... and thanks Forts for reporting it.

Mike

 

[Forts]

I too noticed it a while back, but some of the systems I monitor were still being built out so I sort of chalked it up to that. But after seeing a few sites last night showing an ID of 0 (which I knew was invalid) I thought "maybe I should actually look into this" haha. Anyways glad to hear its working good for you too.

 

[IanWraith]

Hello Mike & all

Thanks, Ian, for fixing... and thanks Forts for reporting it.
Mike

No problem. All we know about Connect and Capacity Plus is what we on this group have managed to discover by watching these systems in operation and its quite likely we haven't got it quite right yet. So if anyone spots any problem with DMRDecode or finds any new information please post it to this forum.

Regards

Ian

 

[DaveH]

I'm using Build 49 to gather info on TRBO systems in the Ottawa area.
Interesting to note in RR DB a Glentel system Network ID 202 in Ballantrae Ont.
which is 100's of km west of Ottawa, which has the same ID as several sites in Ottawa.
Fortunately the Site ID (4) is not duplicated, which would cause me concern.
(I found 1,2,3, and 5 so far) .

Looks like a network with a fair geographical spread; will be intersting to
see any other Glentel sites which also belong or is everything of theirs one
big network, at least in this part of the country...

The other frequency listed in TAFL for Ballantrae is 452.5875 (interestingly,
recycled frequencies from defunct Enbridge EDACS).

Dave

 

[Forts]

Best as I can tell thru my various travels, network 202 is a wide area network supported by various carriers thru the area. Looks like it stretches from London to the West to Ottawa in the East. Down in the London area frequencies in use are registered to Spectrum Communications.

 

[inigo88]

Thanks for the new build Ian. I have confirmed that the site I am monitoring is showing a Site ID of 10:

1010 000011001010 00001010 0000 (Network 202, Site 10)

Still not sure what the 1010 at the start is for. We know the next 12 bits are ok for the Network ID. So given this info I propose we change the Site ID to the 8 bits after the Network ID.

Well Forts, I just couldn't stay away. I took a hiatus from staring at Connect Plus binary code, but I'm back.

From the quote above, was that taken from an SLCO=10 or 9 message? Looking back in my logs, all of my SLCO messages seem to be four bits shorter than that (24 bits total).

I went back and took a fresh look at some of my old logs armed with this new information:

Network ID: 1-255 (8 bit block)
Site ID: 1-35 (6 bit block)

We now know that the channel grant system used by the XCR9000 site controller does indeed use both a Repeater Radio ID number (from 1-15, 4 bits) and a time slot (1 or 2).

We also know that each control channel broadcasts an adjacent Neighbor List, which contains up to 5 site ID numbers for the five closest adjacent sites.

I went back and looked at some SLCO=10 (and 9) packets from my logs and changed them to 6-bit (1-35) side IDs:

SLCO=10 - Network ID & Site ID

(SLCO=10 for control channel, SLCO=9 for voice channel)
Control Channel frequency on the left, corresponding SLCO=10 packet on the right.

454.0375     0000 01110111 00 000100 0000
454.0500     0000 01110111 00 000001 0000
454.5250     0000 01110111 00 000011 0000
461.3000     0000 01110111 00 000010 0000
463.4375     0000 01110111 00 000101 0000
453.0125     0000 01110111 00 000110 0000
                      ^         ^    
              (Network ID)   (Site ID)

Corresponds to this list of control channels and their Network & Site IDs:

454.0500 - Network: 119 - Site: 1
461.3000 - Network: 119 - Site: 2
454.5250 - Network: 119 - Site: 3
454.0375 - Network: 119 - Site: 4
463.4375 - Network: 119 - Site: 5
453.0125 - Network: 119 - Site: 6


I also long suspected that CSBKO=1 FID=6 packets were the adjacent neighbor list, because they are broadcast so often on the control channel. Tonight I was able to confirm this!

CSBKO=1 FID=6 - Neighbor List

I took the CSBKO=1 packets from two different site control channels that were part of the same system and compared them. Knowing the site ID corresponding to each frequency, it became super obvious what was going on. The CSBKO=1 packet excludes the current Site ID, and shows a list of up to the 5 nearest neighboring Site IDs!

461.300 MHz:  CSBKO=1 + FID=6 0000 000100 000011 000001 0000 000101 00 000110 000000000000000000001101   (On Site 2)

				     4      3       1		5	 6			   13			

454.525 MHz:  CSBKO=1 + FID=6 0000 000100 000010 000001 0000 000101 00 000110 000000000000000000000100   (On Site 3)

				     4      2       1           5        6			    4

This says:

Site 2 neighbors: 4, 3, 1, 5, 6
Site 3 neighbors: 4, 2, 1, 5, 6

I'm still not sure what the last 4 bits do. I thought it might have to do with the registration process, but I really don't know. It stays consistent per site control channel over long periods of time in my log files. However I was able to compare the neighbor list for the same site and control channel (461.300, site 2) from two different log files for two different days, and noticed an interesting result:

CSBKO=1 + FID=6 0000 000100 000011 000001 0000 000101 00 000110 000000000000000000001101

			4     3       1		  5	   6			     13

CSBKO=1 + FID=6 0000 000100 000011 000001 0000 000101 00 000110 000000000000000000001011

			4     3       1		  5	   6			     11

As you can see the adjacent neighboring Site IDs didn't change, but that end value did. Any theories on what it might do?

The site neighbor list is used is used for roaming when the radio loses contact with the current site. If this happens, there are four layers of priority for the radio to find a new site.

1. Check the pre-programmed control channel of the "Preferred Site."
2. Check the control channel of the last site ID the radio was registered to.
3. The radio periodically saves the neighbor list of the last-registered site into memory, so if the first two don't work the radio will start checking the control channels for each neighbor. It does this by taking the neighbor site IDs and correlating them to pre-programmed control channels in the radio's "Network Frequency File."
4. If it can't find anything from the neighbor list, it will finally go through every control channel in the radio's pre-programmed "Network Frequency File" until it finds something.

Unfortunately, I'm not exactly sure how the last four digits of the neighbor list packet assist in this process.

 

[inigo88]

After comparing a few more CSBKO=1 packets, I'm not convinced I have it as well figured out as I thought. There appears to be a 4 bit block in the middle that sometimes has a value (shown with ?) along with the one at the end. However if it's not right, it's definitely pretty close.

454.525 (site 3) CSBKO=1:

CSBKO=1 + FID=6 0000 000100 000010 000001 0000 000101 00 000110 000000000000000000000101

			4      2      1     	  5	    6			      5


461.300 (site 2) CSBKO=1:

CSBKO=1 + FID=6 0000 000100 000011 000001 0000 000101 00 000110 000000000000000000001110

			4      3      1  	  5         6			      14

454.0375 (site 4) CSBKO=1:

CSBKO=1 + FID=6 0000 001100 000101 000000 1000 000001 00 000110 000000000000000000000101

		       12      5      0    8?    1          6			      5


454.0500 (site 1) CSBKO=1:

CSBKO=1 + FID=6 0000 001100 000100 000001 0100 000110 00 000000 000000000000000000001011

		       12      4      1     4?    6         0			     11


463.4375 (Site 5) CSBKO=1:

CSBKO=1 + FID=6 0000 010000 000011 000000 0100 000110 00 000010 000000000000000000001001

			16     3      0     4?    6	    2			      9

 

[Forts]

Good job! I haven't had a chance to look at the systems around me yet but should be able to sometime today, then I can compare notes with you. Certainly looks like you are on the right track though!

 

[IanWraith]

Hello

Nice info Inigo88 !!

I'm a little busy at the moment but will try my best to incorporate your information into a new build of DMRDecode by the end of the month.

Regards

Ian

 

[Forts]

I've been looking at some of my logs and here is what I have observed:

I have 3 sites logged for the system I was analyzing, Site 1, 3 & 5. Here is the CSBK info from their control channels:

Site 1 - 0000001000000011000001000000010100000000000000000000000000001011
Site 3 - 0000000100000010000001000000010100000110000000000000000000001100
Site 5 - 0000000100000011000000100000010000000110000000000000000000001110

I tried the spacing that you suggested and it just didn't jive for me, so after some tinkering here is what I came up with:

Site 1 - 00 000010 00 000011 00 000100 00 000101 00 000000 000000000000000000001011
Site 3 - 00 000001 00 000010 00 000100 00 000101 00 000110 000000000000000000001100
Site 5 - 00 000001 00 000011 00 000010 00 000100 00 000110 000000000000000000001110

With this format I see the following neighbour sites:

Site 1 - 2, 3, 4 & 5
Site 3 - 1, 2, 4, 5 & 6
Site 5 - 1, 3, 2, 4 & 6

So that certainly seems to jive for me. And applying this format to a couple different networks in my region, it seems to fit too.

I'm also in the same boat as you when it comes to those last few bits if the string. Absolutely no clue yet as to what they are indicating.

 

[Forts]

And using your example of:

461.300 MHz:  CSBKO=1 + FID=6 0000 000100 000011 000001 0000 000101 00 000110 000000000000000000001101   (On Site 2)

				     4      3       1		5	 6			   13			

454.525 MHz:  CSBKO=1 + FID=6 0000 000100 000010 000001 0000 000101 00 000110 000000000000000000000100   (On Site 3)

that reworks to:

461.300 MHz:  CSBKO=1 + FID=6 00 000001 00 000011 00 000100 00 000101 00 000110 000000000000000000001101   (On Site 2)

				     1      3       4		5	 6			   13			

454.525 MHz:  CSBKO=1 + FID=6 00 000001 00 000010 00 000100 00 000101 00 000110 000000000000000000000100   (On Site 3)
                                     1      2        4        5         6

 

[inigo88]

Oh wow! This is why you need to get a second opinion when you're tired and have been staring at code for too long! As usual Forts is right!

Here's the reworked example of all six sites from earlier. Everything just falls into place now!

454.525 (site 3) CSBKO=1:

CSBKO=1 + FID=6 00 000001 00 000010 00 000100 00 000101 00 000110 000000000000000000000101

		      1         2         4 	   5	     6			      5


461.300 (site 2) CSBKO=1:

CSBKO=1 + FID=6 00 000001 00 000011 00 000100 00 000101 00 000110 000000000000000000001110

		      1        3          4	   5         6			      14

454.0375 (site 4) CSBKO=1:

CSBKO=1 + FID=6 00 000011 00 000101 00 000010 00 000001 00 000110 000000000000000000000101

		      3        5          2        1          6			       5


454.0500 (site 1) CSBKO=1:

CSBKO=1 + FID=6 00 000011 00 000100 00 000101 00 000110 00 000000 000000000000000000001011

		      3         4        5         6          0			       11


463.4375 (Site 5) CSBKO=1:

CSBKO=1 + FID=6 00 000100 00 000011 00 000001 00 000110 00 000010 000000000000000000001001

		      4        3          1         6	     2	                        9

 

[Forts]

A second set of eyes is almost mandatory for this stuff. You can only stare at 1's and 0's for so long before going cross eyed . Glad to see that format fits all your examples too. Now to start guessing at what the other bits are for!

 

[inigo88]

Here's a new one, found in my logs from 454.525 (site 5).

I believe this has to do with either Registration or the "Radio Check" feature. Radio check happens when the site controller has reason to believe that a user radio is no longer on the system (roamed out of range). The radio check message is an "are you still there?" query. If the radio replies, it stays in the list of registered radios in the site controller. If no reply is heard, the site controller de-registers the radio.

Each of these were seen only once (not repeated) about five minutes apart:

Unknown CSBK : CSBKO=24 + FID=6 101101011011101110000010 101101011110000010001011 0000000000000101
                         
 				  Radio ID: 11910018       Group ID: 11919499			5

Unknown CSBK : CSBKO=24 + FID=6 101101011011101110000010 101101011110000010001011 0000000000000101

				  Radio ID: 11910018	   Group ID: 11919499			5

Unknown CSBK : CSBKO=24 + FID=6 101101011011101110000010 101101011110000010001011 0000000000000101

				  Radio ID: 11910018	   Group ID: 11919499		        5

Unknown CSBK : CSBKO=24 + FID=6 101101011011101110000000 101101011110000010001011 0000000000000101

				  Radio ID: 11910016	   Group ID: 11919499			5

Unknown CSBK : CSBKO=24 + FID=6 101101011011101110001000 101101011110000010001011 0000000000000101

				  Radio ID: 11910024       Group ID: 11919499			5

Unknown CSBK : CSBKO=24 + FID=6 101101011011101110000100 101101011110000010001011 0000000000000101

				  Radio ID: 11910020       Group ID: 11919499			5

 

[Forts]

I don't think I've ever seen that activity on my systems... Certainly looks logical though.

 

[inigo88]

Worth a try - collect a large log file on each control channel (leave it running for an hour or so). CTRL+F through it looking for "CSBKO=0" through "CSBKO=9."

We're still kind of in the 'we don't know what we don't know' stage... All we really know is:

CSBKO=1 - Control Channel Neighbor List
CSBKO=3 - "Trunk-To" channel grant
SLCO=10 - Control Channel Network/Site ID
SLCO=9 - Voice Channel Network/Site ID

There's still an entire system of radio registration and de-registration (powering up, changing channels, powering down). "Radio Check" queries. Emergency call activation. Private calls and multi-group calls. Paging (called "Call Alert"). There is a lot left to still be figured out!

I went back and looked at some old logs from 2011 I had laying around to take another look at the CSBKO=3 "Trunk-To" channel grants. (This predates my system's change to the long talkgroup and radio IDs with the network ID in front.)

Old format from 2011 (463.6875)

Unknown CSBK : CSBKO=3 + FID=6 000000001110101010010000 000000001100001101011100 00100 00000000010

				   Radio ID: 60048	    Group ID: 50012    RptID: 4		 2

Old format from 2011 (454.525)

Unknown CSBK : CSBKO=3 + FID=6 000000001110101010001001 000000001100001101011111 00111 00000000010

				   Radio ID: 60041	    Group ID: 50015    RptID: 7          2

I'm still not sure what the 2 (binary 10) is on the end, but every CSBKO=3 packet I've been able to find has it. I don't think it's the TDMA time slot. I definitely think we have the Repeater Radio ID (LCN) correct though. Since we know that the repeater radio ID can range from 1-15, I am curious if the number in this packet ever goes any higher than 15? For example, the repeater radio ID + 15 could mean it is assigning the second time slot? This is all a guess at the moment, but I set aside 5 bits for the repeater radio ID field just in case.

 

[inigo88]

Hello

Nice info Inigo88 !!

I'm a little busy at the moment but will try my best to incorporate your information into a new build of DMRDecode by the end of the month.

Regards

Ian

Thanks Ian! Since a lot of this is still conjecture, it would be nice if you could also leave the binary data, or at least the parts we haven't yet figured out... Like the unknown ending bits on CSBKO=1, CSBKO=3 and CSBKO=24 (which could probably still be called an "Unknown System Message" or something). Thanks again!

 

[Forts]

Thanks Ian! Since a lot of this is still conjecture, it would be nice if you could also leave the binary data, or at least the parts we haven't yet figured out... Like the unknown ending bits on CSBKO=1, CSBKO=3 and CSBKO=24 (which could probably still be called an "Unknown System Message" or something). Thanks again!

Yes I was thinking the same. Or have some sort of 'verbose' or 'diagnostic' option that could be enabled to show all the raw data.

I took another look at some of my logs and found:

Unknown CSBK : CSBKO=17 + FID=6 111111111111110011011010 000000000001011110101111 0000010100000000
					16776410 (group)                    6063 (radio)
Unknown CSBK : CSBKO=18 + FID=6 000000000001011110101111 111111111111110011011010 0000010100000000
			          6063 (radio)			         16776410 (group)
Unknown CSBK : CSBKO=24 + FID=6 000000000001011110101111 000000000101011010111011 0000000000000010
				6063					22203 (group)

The CSBKO=17 and the CSBKO=18 were only a matter of seconds apart. It almost looks like a request followed by an acknowledgement perhaps? In this case group 16776410 is some sort of site wide all call I believe, and 22203 is a regular talkgroup. And I think you are bang on with the channel grants too... That certainly looks plausible to me.

 

[Forts]

I've also logged these unknowns on a voice channel:

Unknown CSBK : CSBKO=12 + FID=6 0000000000100111101110000000101100000000000000000000000000000000

Unknown CSBK : CSBKO=12 + FID=6 0000000000100111101100010000101100000000000000000000000000000000

Unknown CSBK : CSBKO=6 + FID=6 0000000000100111101100010001100000001011000000000000000000000000