[PATCH 5/8] agch/pch: Use PCH for AGCH msgs

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.de
Mon Feb 24 09:38:14 UTC 2014


Hi

On 22.02.2014 09:08, Holger Hans Peter Freyther wrote:
> On Sat, Feb 22, 2014 at 12:36:06AM +0100, Jacob Erlbeck wrote:
>> This patch extends paging_gen_msg() by adding an output parameter
>> is_empty that is true, if only a paging message with dummy entries
>> has been placed into buffer.

I also would like to remove the paging_add_imm_ass() because IMO it
doesn't make much sense any longer.

>> This feature is then used by
>> bts_ccch_copy_msg() to insert an AGCH message if is_empty is true
>> and there are more entries in the AGCH queue than fit into the
>> reserved blocks.
> 
>> +	struct gsm48_system_information_type_3 *si3 =
>> +		GSM_BTS_SI(bts, SYSINFO_TYPE_3);
>> +	int bs_ag_blks_res = si3->control_channel_desc.bs_ag_blks_res;
> 
> it is the third place we access bs_ag_blks_res and it will not be the
> last one (src/osmo-bts-sysmo/oml.c). Here we don't check if the SI3 is
> valid or not. What do you think of creating an accessor method in common
> instead that will return a default value? 

I'm note sure, whether a default value would make any sense here,
because is has the match the SI3 that is transmitted over they air
anyway. Does it make sense to have a complete default SI3 that can be
transmitted _before_ a valid SI3 has been received via RSL?

But an accessor function would be a good thing anyway.

This way even the paging code
> could initialize the bs_ag_blks_res to the default?

> 
> If I understand that correctly. In case we generated an empty paging
> message and we have fewer AGCH messages in the queue than reserved blocks,
> we do send an empty paging message. What is the reason for that? It
> seems to complicate the code, is it a spec requirement?

No it's not a spec requirement. It's just a minimal change in comparison
to the old behaviour. Let's remove it.
> 

Jacob




More information about the OpenBSC mailing list