Jacob,
On Fri, Feb 14, 2014 at 12:22 PM, Jacob Erlbeck <jerlbeck(a)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