This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Jacob Erlbeck jerlbeck at sysmocom.deOn 13.02.2014 14:01, Alexander Chemeris wrote: > I believe that we should start using PCH for IMM.ASS as soon as we > exhaust capacity of the AGCH. > > Imho, IMM.ASS has higher priority than PCH, as paging will lead to > IMM.ASS anyway, and if AGCH is congested, there is no point in sending > any more paging. I'm not so comfortable with that. We would then have a decreasing probability within a 51-multiframe of having a PCH message being cannibalized by a AGCH message. That in turn would IMO lead to unfair treatment of MS because of the paging group they belong to (AFAI understand GSM 05.02, 6.5.1 vi and 6.5.2). In addition, I didn't understand the 'extended paging' (see GSM 04.08, 3.3.2.1.1 b) well enough, to estimate the implications here. I'd rather prioritize paging messages over IMM.ASS.* to stay on the safe side until we have measurements or simulations that suggest otherwise. > >> 6. What do you finally think about calculating agch_max_queue_length? >> What is the right way to calculate it from your point of view? > > You could also consider another approach. Instead of limiting the > queue length - limit the age of IMM.ASS in the queue. Yes, this was my first approach, too. But it is more complex and we still need to determine max-age which suffers from the same difficulties like the max-queue-length computation. I also thought about having to queues: - One for non-reject messages (IMM.ASS.CMD and IMM.ASS.EXT) that is unlimited and has a high prio - Another for the reject messages only with a lower prio, where messages older that 3(S+T/2) RACH slots are silently dropped But I have the impression, that a simpler solution (like those I stated in the other mail) will take us far enough with much less efforts. Jacob