hi,
i like to do extensions to the RSLms layer of osmocom. before that i like to ask and discuss if this would be the correct way:
instead directly of calling l1ctl_* functions of l1ctl.c, i would like to use RSL messages between layer 2 and layer 3. the lapdm.c would then convert these messages and call l1ctl_* functions. (maybe i could split up lapdm.c into lapdm.c and layer2.c. the selecting the handler for an RSL request could be made at layer2.c, as well as selecting the right handler for the frames received from layer1. only the lapdm part could be handled in lapdm.c. )
the RACH request could be sent using RSL_MT_CHAN_RQD, the confirm could be the same message type, but i prefer to invent a new one: 0x18, but using the same IE layout. also including RSL_IE_MS_POWER_PARAM with the RACH request, could tell the layer 1 about usage of power and TA (which is normally 0 for RACH request).
the (UNIT) DATA request may also include RSL_IE_MS_POWER_PARAMS. if omitted, the stored value from the last message with RSL_IE_MS_POWER_PARAMS could used.
the (UNIT) DATA indication and request of SACCH may include RSL_IE_L1_INFO IE to receive power and timing control as well as send the actual power and timing advance. i could handle these IE at layer 3 (radio ressource) and forward them to layer 1 (RSL_IE_MS_POWER_PARAM) depending on the supported radio power and on special VTY settings to mess with power and fake timing advance.
regards,
andreas
Hi Andreas,
On Wed, Jun 30, 2010 at 09:56:57AM +0200, Andreas.Eversberg wrote:
i like to do extensions to the RSLms layer of osmocom. before that i like to ask and discuss if this would be the correct way:
I agree with all of your points. Feel free to go ahead :)
And yes, splitting in layer2.c and lapdm.c sounds like a reasonable plan, too.
Regards, Harald
baseband-devel@lists.osmocom.org