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/.
Alexander Chemeris alexander.chemeris at gmail.comJacob, On Fri, Feb 14, 2014 at 12:22 PM, Jacob Erlbeck <jerlbeck at sysmocom.de> wrote: > On 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. Sending more paging messages only increases a number of IMM.ASS messages being sent out. Thus it doesn't make sense to prioritize PCH over AGCH. Another question is how do we schedule IMM.ASS in case we cannibalize PCH. IIRC, an MS could be sleeping during paging groups it doesn't belong to and thus might miss the IMM.ASS we're sending. We have to check this against the standard. >>> 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 was thinking about scheduling IMM.ASS and at the time of its arrival. May be even replacing a queue with a fixed-size round-robin "map". In this case there should be no issues with understanding if IMM.ASS is too late, as we'll know when exactly it's to be sent. This changes the current code structure, though, and I haven't estimated the effort required to do that. > 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. Which solution are you referring to? -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru