P25 Neigbor site - auto tracking

[Radiotech012]

Would it be possible to implement an option switch, in a P25 channel, to auto add neighbor sites to a notional CC monitor list.
Then, monitor the RSSI of those neighbor sites and begin monitoring only if/when the CC RSSI exceeds a predetermined level?
In other words, a simple RSSI voting system. A user defined Max number of Control channels could be assigned to prevent the
tuner from attempting to add too many active CC's at any one time & ensure that only the strongest CC's are monitored.

Possibly up to 2 alternate/neighbour CC's (that exceed the preset RSSI level) is likely all you would need.

In this way, it may be possible for SDRTrunk to roam across sites in a mobile environment.

[TRENT310]

My further comment on this is that on certain system implementations, all possible neighbouring sites get advertised. In some cases between simulcast and multicast clusters this may be over a dozen possible neighbouring logical sites - especially those systems built for dense, urban, in-building coverage. Rather than hard limiting a specific number of neighbouring sites to monitor (the number of which can be wildly different from one effective coverage "cell" to another), the roam RSSI monitoring worker/resource could hop between those frequencies/channels as advertised by ADJ_STS_BCST as it is only sampling RSSI and/or BER decode success rate for determining outbound control channel reception quality, and optionally the confirmation of valid site identification based on NAC (unreliable on certain MFID systems but available very frequently) or RFSS_STS_BCST (more reliable across vendors but requires a longer receive sample time as well as unpacking TSBKs), but not actually dwelling on them for any longer period of time to decode further opcodes. The C/F/V/A flags could be honoured as these indicate if a site has failed or isolated despite still being advertised. Depending on the monitoring purpose and application, sites in such conditions may be of lesser or more interest. (Less interesting for those using SDRTrunk merely for traffic or content, but more interesting for those using SDRtrunk to identify and log system problems and impairments.)

This would assist when SDRTrunk is operated in a mobile environment, so that its own tuner resource can benefit from site roaming in the same fashion as a Subscriber Unit (SU) as it travels throughout coverage areas and different systems without manual user intervention. Further options to refine this could be a user-selectable restriction of RFSS, restriction of System ID, or restriction of WACN roaming which is also in line with similarly configurable coverage/roaming types available on SU devices, as well as allowing a site preferences or restrictions per "playlist" as certain talkgroups may be known to be restricted to certain System/RFSS/Site ID combinations and may never be carried or allowed on other sites. As a passive receiver, SDRTrunk will never be able to attempt and receive its own GRP_AFF_RSP but it may also learn based on receiving Group Affiliation Response (GAV) values seen for a given talkgroup directed to valid system Subscriber Units which may attempt to roam (ie. Location Register LOC_REG_RSP) or affiliate to a talkgroup at a given site. ie, if a given talkgroup registration or affiliation is consistently responding on its outbound flagged GAV or RV of DENIED or REFUSED then it should not be preferred when a "playlist" contains those talkgroups. This information can be used to direct any automatic roaming functions in a smarter fashion.