Hi Ivan,
On 13.02.2014 13:48, Ivan Kluchnikov wrote:
First I want to summarize you previous ideas, which I
think we should implement:
1. we shouldn't send Delete Ind message for IMMEDIATE ASSIGNMENT REJECT messages
2. Just drop IA REJECTs, if L > maxL/2 (am I right?)
I'm not sure about
which factor to use, especially if maxL is very low.
But I think it's a good start. Maybe we need some simulations to
fine-tune. In addition, we should add stat counters for that.
3. Use agch_queue_length and agch_max_queue_length
names
4. Implement function bts_agch_update_max_queue_length, that is only
called after config/bs_ag_blks_res is changed/set (do you know places
where bs_ag_blks_res is changed/set?)
We've to check. If any of the input
values changes, we have to update.
But let's put that call into agch_enqueue initially. Moving this to
other places is just an optimization and I would like to defer it, until
the rest has proved to work.
5. Yes, you are right, we can use PCH blocks when
needed, it is good
question, why (master and jolly/trx) do not use PCH blocks when
needed.
I've just set up a test case with NITB and two phones, and modified
code
where only the PCH blocks are used for AGCH and PCH and it worked pretty
well.
Actually we already have function for that:
int paging_add_imm_ass(struct paging_state *ps, const uint8_t *data,
uint8_t len);
Moreover we should also determine when we should start to use PCH for
imm assign messages and what we should do with agch_max_queue_length
in this case, what do you think about it?
I would use PCH for AGCH messages, when
there is not pending paging
message. And I wouldn't use paging_add_imm_ass() but just call
bts_agch_dequeue() when there is no paging message.
I wouldn't do this in paging_gen_message() but outside of it, since it
is no paging message. agch_max_queue_length should be based on
ag_blks_res + gsm0502_get_n_pag_blocks() (or something delivering the
same result) then.
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?
I'm not sure
yet. Since there is a direct relationship between number of
RACH bursts and CCCH blocks per multiframe, there could be a way to
simplify the calculation. One have to adjust it, if there are optional
CCCH blocks that are not AGCH/PCH (like CBCH), but even if that is not
taken into account, the error might be tolerable.
Jacob