status layer 3
laforge at gnumonks.org
Mon Mar 8 17:06:48 UTC 2010
On Mon, Mar 08, 2010 at 12:03:20PM +0100, Andreas.Eversberg wrote:
> my last mail was written yesterday and somehow sent today.
you sent it to baseband-devel-bounces@ instead of baseband-devel@,
so it was dropped by mailman. I then 'forged' a mail with your
sender address and posted it to the ML today.
> meanwhile i decided to work with GIT for the following reasons:
great, thanks for your understanding.
> anyway here is my first issue:
> the messages between layer 3 (radio ressource) and layer 2 have
> primitives starting with DL_*.
> e.g. DL_RANDOM_ACCESS_REQ is used to send a CHANNEL REQUEST on the RACH.
> and DL_ESTABLISH_REQ is used to establish a layer 2 link on SDCCH or
> both messages carry layer 3 messages, like CHANNEL REQUEST or LOCATION
> UPDATE REQUEST. using msgb between layer 2 and 3 is not enough, because
> i need to exchange additional informations with layer 2. these are the
> primitives themselves, and in case of DL_ESTABLISH_REQ the channel
> information for frequency, channel type, slot, ect.
We have so far decided to use something called "RSLms", i.e. RSL for the
The idea is that many of the operations between a MS L2 and L3 are
similar to those between a BSC and the BTS. After all, the L2
terminates in the BTS, and L3 at BSC/MSC, so RSL is a 'remote-control
So layer3 sends a msgb with a RSLms header. In the RSLms header, we
have things like channel number and link id, exactly like on the
So far, I have only implemented partial RLL support, as this is a
real 1:1 mapping with no need to modify RSL in any way.
Let's assume we want to establish a dedicated channel _after_ the
RACH request has been sent and immediate assign has been received:
L3 sends RSL RLL ESTABLISH REQUEST with LOC UPD REQ as L3_INFO
L2 converts this in SABM with LOC UPD REQ as payload
L1 sends the packet to the GSM network
L1 receives response from the GSM network
L2 generates RSL RLL ESTABLISH CONFIRM to L3
More information about the baseband-devel