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.ruHi Jacob, Thank you for your comments and ideas! 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?) 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?) 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. 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? 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? 2014-02-13 15:07 GMT+04:00 Jacob Erlbeck <jerlbeck at sysmocom.de>: > Hi, > > On 11.02.2014 15:07, Jacob Erlbeck wrote: >>> 2. Implemented calculation of agch queue length. >>> Bts should calculate allowed length of agch queue, because bts should >>> send imm assign message before immediate assignment procedure will be >>> aborted by MS. >>> Imm assign message can be queued no longer than T3126, so agch queue >>> length should be equal (T3126 / 51 ) * bs_ag_blks_res. > > My understanding of GSM 05.02 3.3.2.3, 6.5.1 v), and clause 7 table 5 > was, that bs_ag_blks_res defines the number of blocks _reserved_ for > AGCH an SI messages per 51-multiframe, but does not _limit_ it. > Is this correct? If yes, is there a reason why the implementations > (master and jolly/trx) do not use PCH blocks when needed? > >> >> I'm not sure about the correctness of the max length calculation because of >> a) There are other timers/conditions that are influenced by the queue delay: >> - T3101 limits channel reservation on the network side. >> - Only the last 3 CHANNEL REQUEST messages are matched by the MS >> against incoming IMMEDIATE ASSIGNMENT messages. > > More precisely, this limits the allowable delay to 3*(S+T/2) while > CHANNEL REQUESTs are being sent. After the last one, T3126 is relevant. > At least, this is my understanding of GSM 04.08, 3.3.1.1.2. So I'd > rather drop that requirement, since 3S+1.5T > 2S+T. > > Jacob > -- Regards, Ivan Kluchnikov. http://fairwaves.ru