14 Feb
2014
14 Feb
'14
11:22 a.m.
On 13.02.2014 14:01, Alexander Chemeris wrote:
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
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.