sysinfo: Fix scheduling of downlink SACCH information
The existing algorithm (present since 2012!) failed to work in the sole case that only *one* SACCH filling type was present. So if you had your BTS configured to only broadcast SI5, but not broadcast SI5ter, SI6 or any other SACCH filling, it would send the SI5 message only once on a newly-established channel, and never again. The old code was working for more-than-one SACCH filling, as well as for no SACCH filling at all. Let's also add a NOTICE message if there is no SACCH filling available at all. This is highly unusual and definitely a noticeable event. Change-Id: Ica801f9b9c118f00d9e3dc2780b3123e925f59b4 Closes: OS#3057 Related: OS#2963
This commit is contained in:
parent
f72bdfaaa9
commit
7d648b4657
|
@ -163,13 +163,15 @@ uint8_t num_agch(struct gsm_bts_trx *trx, const char * arg)
|
|||
/* obtain the next to-be transmitted dowlink SACCH frame (L2 hdr + L3); returns pointer to lchan->si buffer */
|
||||
uint8_t *lchan_sacch_get(struct gsm_lchan *lchan)
|
||||
{
|
||||
uint32_t tmp;
|
||||
uint32_t tmp, i;
|
||||
|
||||
for (tmp = lchan->si.last + 1; tmp != lchan->si.last; tmp = (tmp + 1) % _MAX_SYSINFO_TYPE) {
|
||||
for (i = 0; i < _MAX_SYSINFO_TYPE; i++) {
|
||||
tmp = (lchan->si.last + 1 + i) % _MAX_SYSINFO_TYPE;
|
||||
if (!(lchan->si.valid & (1 << tmp)))
|
||||
continue;
|
||||
lchan->si.last = tmp;
|
||||
return GSM_LCHAN_SI(lchan, tmp);
|
||||
}
|
||||
LOGP(DL1P, LOGL_NOTICE, "%s SACCH no SI available\n", gsm_lchan_name(lchan));
|
||||
return NULL;
|
||||
}
|
||||
|
|
Loading…
Reference in New Issue