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/.
Ivan Kluchnikov Ivan.Kluchnikov at fairwaves.ruJacob, Your implementation (jerbeck/agch-queue branch) looks reasonable. But from my point of view we should add sending rsl Delete Ind message to bsc and implement final check (in bts_agch_dequeue function) that immediate assignment message is still valid for ms. My plan is to test your code and add sending rsl Delete Ind message to bsc. After that we can try to implement lifetime parameter for immediate assignment message. 2014-02-17 13:59 GMT+04:00 Jacob Erlbeck <jerlbeck at sysmocom.de>: > Hello > > On 16.02.2014 12:20, Alexander Chemeris wrote: >> 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'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. > > That might be true for many cases, but there might be other cases like > issuing a paging request at the end of a short term AGCH overload where > it would make sense, to not drop it but some IMM.ASS.REJ instead. > Another case: all IMM.ASS.* messages are about TCH's and the paging > request is for SDCCH (or vice versa). So until there are simulations > covering all sensible combinations and all of them suggest that always > prioritizing AGCH over PCH is really worth the drawbacks, I won't do > that. It is not required by the spec either, which provides AG block > reservation to cope with frequent PCH overloads instead. There might be > reasons, why they didn't suggest this kind of prioritization and I'd > rather be careful until I know that these are not technical ones. > > So I've implemented the usage of _free_ PCH blocks for IMM.ASS which is > IMO a big improvement over the current situation and without any > drawback I know of. In addition, I've added dropping of IMM.ASS.REJ > based on AGCH queue length, to further increase the AGCH queue's drain > rate. This is beyond the spec too, but doesn't touch another procedure > at least. > > I suggest to gather real live experiences with these changes and > implement more sophisticated solutions when need arises. > >> >> 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. > > Paging groups are not relevant for the RR connection establishment > procedure (AFAICS). According to GSM 04.08 3.3.1.1.3.1 and .2 IMM.ASS.* > is only restricted to the "same CCCH timeslot" where the CHANNEL REQUEST > has been sent, "there is no further restriction on what part of the > downlink CCCH" the IMM.ASS.* is sent. > >> >>> 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? >> > > See <52FA2E91.1090605 at sysmocom.de> (1) and (2) and above. > > Jacob > -- Regards, Ivan Kluchnikov. http://fairwaves.ru