Integration with BrandMeister

[cyanide-burnout]

Today I found a presentation of the project on YouTube. The presentation highlighted the problem that the BrandMeister has a pinning of groups to time slots. We (BrandMeister Team) always tell: let's use proper protocol for each task. I would like to suggest you to design a new protocol, that could be suitable for your case. We can provide group affiliations, multiple streams and private simplex calls especially for your Tier 3 solution (ATM we already have implementation of DMRA AIS, but it is overkill).
If you have an interest, please contact me in Telegram. In case if you have no my contact, please do it through BrandMeister General Support group.

[kantooon]

Thanks for reaching out Artem! I agree with you that having a custom protocol for the data stream would be ideal. I did try to open a Jira ticket when I first started on this, but either it was open in the wrong place or I did not do a good job at explaining what I wanted to do because it got summarily closed by someone.

Unfortunately, I have not Telegram, I mainly use email and such (you can find my address in the commit log).
But there are a number of things that could be done with such a custom protocol:

• dynamic subscription and unsubscription of talkgroup streams based on registrations (sort of like what you already do with dynamic talkgroups, minus the part where the user needs to send a voice LC header and key up the whole network)
• a central registry of registered users and their location on the network, so you can route private call and SMS requests to the appropriate host
• a simple protocol for passing private call and SMS requests / receipt confirmation between the right repeaters
• not sure yet about handling mobility between different sites, because DMR does not standardise that and apparently each radio manufacturer does it in their own way. I need to do additional experimentation with that (right now there are not many people running this and who could help)

I have not much insight into what limitations might exist on the network infrastructure side and what would be the best way to keep IP traffic and load manageable on your side. I think many of the same solutions from TETRA could apply here as well. Is there some sort of dev mailing list where this can be discussed?

[cyanide-burnout]

Thank you Adrian for quick answering.

you can find my address in the commit log

Will do on the next iteration :)

Is there some sort of dev mailing list where this can be discussed

Unfortunately we use Telegram only :) But in our case I'll add @stefansaraev into CC.

First I want to ask you to look at https://wiki.brandmeister.network/index.php/Open_DMR_Terminal_Protocol and https://wiki.tetrapack.online/books/tetra/page/brew

subscription and unsubscription of talk-group

that's group affiliation. Doable, please check the approach we use in Open DMR Terminal Protocol (ODTP)

sort of like what you already do with dynamic talkgroups

not the best idea by design of Tier 3, better to use native group affiliation

a central registry of registered users and their location on the network

sure BM has it, should registration messages be bidirectional in your case or one way (to BM) will be enough?

a simple protocol for passing private call and SMS requests / receipt confirmation

better to use native data formats of Tier 3

not sure yet about handling mobility between different sites

It's done by BM Core, in case of TetraPack Core (TPC) we distribute location registrations between SwMI as well.

I think many of the same solutions from TETRA

Not fully applicable, at least BM uses unidirectional routing and cannot do OACSU, for TETRA TMO <--> DMR Tier 2 bridging we do OACSU restoration on TPC side.

• Could you please think about using UUID for call session's identification?
• Would you like to use UDP or TCP or WS as a transport?
• I suggest to use decoded DMR structures instead of MAC-level bursts (please see ODTP)

[kantooon]

First I want to ask you to look at https://wiki.brandmeister.network/index.php/Open_DMR_Terminal_Protocol and https://wiki.tetrapack.online/books/tetra/page/brew

Thanks for the pointers, I'll need to do a little bit of reading now.

sure BM has it, should registration messages be bidirectional in your case or one way (to BM) will be enough?

I think just towards BM to keep a record which MS is present on which site and then update as cell re-selection happens. One thing is that during a site handover the MS may not have a chance to de-register from it's previous site, so there should be some periodic presence check PDUs to remove stale records from the controller. Didn't have time to do that yet. Handover procedures are generally different depending on the manufacturer, it's a big headache...

a simple protocol for passing private call and SMS requests / receipt confirmation

better to use native data formats of Tier 3

The way FOACSU works in tier 3 (it's the same thing as OACSU in TETRA - unfortunate naming because OACSU is just normal non-ACK call in DMR...) is that when a call request comes through, the site controller contacts the target MS and only allocates a channel if a reply is received. Sort of the same for SMS delivery in MS-to-MS except usually no dedicated channel is used and the SMS goes over the control channel. So if the target MS is on another site, the controller of that site should do the contacting, and also it should allocate its own payload channels. So I think some sort of state should be stored centrally to allow routing to the right controllers to do the signalling. I'm not sure how it would work with your network architecture, as I understand there are multiple master servers, is it a star topology or something else?

It's done by BM Core, in case of TetraPack Core (TPC) we distribute location registrations between SwMI as well.

Ok then this answers the above point about handover.

* Could you please think about using UUID for call session's identification?

* Would you like to use UDP or TCP or WS as a transport?

* I suggest to use decoded DMR structures instead of MAC-level bursts (please see ODTP)

Ok, will think about it and do more reading. I thought of ASN.1 messages a while ago but may be overkill. I agree MAC PDUs are no good for this type of inter-signalling.

[cyanide-burnout]

I think just towards BM to keep a record which MS is present on which site and then update as cell re-selection happens. One thing is that during a site handover the MS may not have a chance to de-register from it's previous site, so there should be some periodic presence check PDUs to remove stale records from the controller. Didn't have time to do that yet. Handover procedures are generally different depending on the manufacturer, it's a big headache...

Better to have it on both ways and check last-update timestamp when getting new records. Also re-sync on connect with passing the last known timestamp.

non-ACK call in DMR

You mean it doesn't require to setup a normal call? I forgot how DMR T3 works :)
I case of unsuccessful routing we can send you call-release.

I thought of ASN.1 messages a while ago but may be overkill.

We can do everything. But with stable format :)

as I understand there are multiple master servers, is it a star topology or something else

Something else :) Full mesh for realtime traffic, about 40-50 core servers. Register replication has two layers:

• real-time direct replication of location cache between nodes
• near-realtime replication of persistent location data and profiles via redundant data hubs

[kantooon]

You mean it doesn't require to setup a normal call? I forgot how DMR T3 works :) I case of unsuccessful routing we can send you call-release.

What I meant is that OACSU in TETRA is called FOACSU in DMR, and OACSU in DMR is just like normal tier II call setup without ACK from the called station. Confusing, I know.

Something else :) Full mesh for realtime traffic, about 40-50 core servers. Register replication has two layers:

* real-time direct replication of location cache between nodes

* near-realtime replication of persistent location data and profiles via redundant data hubs

Very interesting. A complex architecture, that's for sure.
Give me a couple of days to refresh my memory on the private voice and data calls procedures, it's been more than an year since I looked at them. I'll try to come up with an UML diagram of what the site controller needs to do and how we can best hook it up with a central IP network. This was a major limitation previously, I'd be very happy to eliminate it.

Something else that I'm interested in is IP bearer services, with the site controller doing virtual network slicing and routing of IP packets over DMR PHY and then over some sort of VLANs for inter-site (most definitely not through DMR MAC PDUs). You probably have already seen that before in TETRA. Problem is the marketing material of radios doesn't explictly say if the capability is included or not. My best bet right now seems to be the HM785, but please, if you know more about these capabilities and manufacturer solutions and are interested in the topic, share the info with me. I'm pretty tired reading through opaque manufacturer release notes.

[cyanide-burnout]

Something else that I'm interested in is IP bearer services, with the site controller doing virtual network slicing and routing of IP packets over DMR PHY and then over some sort of VLANs for inter-site (most definitely not through DMR MAC PDUs).

In case of TETRA we have various agent software to be running in private networks close to SwMI. It implements local connectivity in private networks (IP-based in Dimetra and Rohill, E1-based in CompactTetra), reduces traffic amount and passes only valuable reassembled messages via WS connection to the core. See here - https://wiki.tetrapack.online/books/presentations/page/hamradio-2024 https://wiki.tetrapack.online/books/presentations/page/hamradio-2025

[kantooon]

I came up with two UML diagrams to illustrate what I think the differences are between private calls on the same site versus private calls over a core network. There may be things in the diagrams that don't make sense from your perspective, so it would be nice to have feedback. I think communication protocols will arise naturally from this discussion.

Diagram 1, local site calls

Diagram 2, network private calls

[cyanide-burnout]

I came up with two UML diagrams to illustrate what I think the differences are between private calls on the same site versus private calls over a core network. There may be things in the diagrams that don't make sense from your perspective, so it would be nice to have feedback. I think communication protocols will arise naturally from this discussion.

Typical TelCo Call-Setup procedure. :) In case of BM we cannot support there normal call setup except rejections. Let's start from group calls, messages and registrations. :)

[kantooon]

Last year I developed a simple UDP protocol to send control messages to MMDVMHost channels. I propose extending this protocol to carry control messages between dmrtc and BM.

Regarding the MS registration and mobility management my proposal is:

1. When a MS registers in dmrtc, a message is sent to BM to update site location information.
2. When a MS de-registers in dmrtc, a message is sent to BM to inform the same.
3. When a MS changes dmrtc site without having had a chance to de-register on previous site, a registration message is sent to BM from the new site, BM then sends an information message containing the MS address to the previous dmrtc site according to BM records.
4. Upon receiving this message from BM, drmtc initiates a presence check for the MS address and if answer is not received, it updates its registration records to remove stale MS.

An early draft of the UDP protocol is attached here. You may wish to have other protocol fields like you have in your other protocols that you linked above. Let's discuss.

Homebrew_DMR_trunking_protocol.pdf

[cyanide-burnout]

Last year I developed a simple UDP protocol to send control messages to MMDVMHost channels. I propose extending this protocol to carry control messages between dmrtc and BM.

Nice )

Few questions:

• authentication / connection establishment / keep alive
• what are units of size fields in your draft (I see there 1, where MS/group addresses have 3 bytes)
• I would recommend to accept registration messages from the network as well
• As I said before it would be better to add timestamp to registration messages (and probably to group subscription/un-subscription as well) because it’s not only you who need to track location ;)
• Since IDs are extracts, I suggest to align them to 4 bytes, which order you prefer? big endian?

[kantooon]

* authentication / connection establishment / keep alive

I think I'll defer to your advice here, you have more experience than me regarding these procedures.

* what are units of size fields in your draft (I see there 1, where MS/group addresses have 3 bytes)

Since all DMR addresses use a 24 bit address space, the units above are one such 24 bit address. If the protocol will eventually carry SMS messages, I'd propose text messages should by default use UTF-16 as the maximum size and most flexible supported format, in such case a size unit would be one UTF-16 character or two bytes. If this inconveniences you, we can switch to using bytes for unit of size but then some field is needed to define the payload format.

* I would recommend to accept registration messages from the network as well

What would be the purpose of these? I can see the purpose for de-registration where dmrtc will perform the presence check and remove stale records, but why registration as well?

* As I said before it would be better to add timestamp to registration messages (and probably to group subscription/un-subscription as well) because it’s not only you who need to track location ;)

Ok, that should be easy. What format for timestamp? Unsigned 64 bit?

* Since IDs are extracts, I suggest to align them to 4 bytes, which order you prefer? big endian?

Easiest for me is the DMR MAC byte order to avoid doing re-ordering. 4-byte alignment is no issue if that is easier for you.

[cyanide-burnout]

I think I'll defer to your advice here, you have more experience than me regarding these procedures.

Let’s then reuse login procedure of MMDVM, but maybe with changed signature

Since all DMR addresses use a 24 bit address space, the units above are one such 24 bit address.

Then let us go your way with 24 bits.

I can see the purpose for de-registration where dmrtc will perform the presence check and remove stale records, but why registration as well?

Site controller may miss deregistration and user is registered somewhere else / or to route calls into net... ?

What format for timestamp? Unsigned 64 bit?

Yes. Better to have it in little-endian byte order

[kantooon]

Let’s then reuse login procedure of MMDVM, but maybe with changed signature

Ok, this is pretty easy, there will have to be some changes in the DMRGateway for this, no big deal I think.

Site controller may miss deregistration and user is registered somewhere else / or to route calls into net... ?

(I should have numbered the tables) that should be the purpose of the message defined in table 4 De-registration message (from network)
I think this is what you meant, right? When a MS registers on a new site, BM is notified. It then looks in its records and sends this message (4) to the previous site that existed in the records, and the previous site has a chance to remove the stale record. I would draw a diagram but I don't have the time right now.

Yes. Better to have it in little-endian byte order

Ok, I'll add them as well. What could complicate things would be daylight saving time transitions and stuff, so I suppose the timestamp should be UTC right?

I shall take some time and try to define a list of opcodes that should not be modified after that. There is 7 bit space for bi-directional opcodes and 6 bit for uni-directional, I don't think there will be any need for more.

I took some time again to look at your Tetrapack presentation, and one thing I like there is PABX/PSTN call support via Asterisk. TS 102 361-4 also has procedures for these types of calls, what stopped me so far was the need of transcoding. Could be interesting in the future.

[cyanide-burnout]

I think this is what you meant, right? When a MS registers on a new site, BM is notified. It then looks in its records and sends this message (4) to the previous site that existed in the records, and the previous site has a chance to remove the stale record. I would draw a diagram but I don't have the time right now.

Could be useful for different cases, such as to synchronize locations after connection downtime or missed deregistrtations.
Maybe if you want to think about resync to make a resync request message with a last-known timestamp

Ok, I'll add them as well. What could complicate things would be daylight saving time transitions and stuff, so I suppose the timestamp should be UTC right?

Yes, normal UNIX timestamp, always UTC. Extra 32-bit field for milliseconds could be also useful. Up to you.

I took some time again to look at your Tetrapack presentation, and one thing I like there is PABX/PSTN call support via Asterisk. TS 102 361-4 also has procedures for these types of calls, what stopped me so far was the need of transcoding. Could be interesting in the future.

We use it not only for PSTN/PUBX calls but also as an IVR for duplex individual calls. AMBE transcoding could be a pain in the a**. Since TETRA uses ACELP mainly we built codecs as an Asterisk’ module. I’ve found custom modules more useful in comparison with implementing SIP or IAX in TetraPack (BrandMesier has few implementations of SIP onboard)

[cyanide-burnout]

then about vocoder i will just save here a link

Well, guys like to risk ;)