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.deHello 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