assignment command / status of RR

[Harald Welte]

Dear Andreas,

sorry once again for my overly delayed answers.  Time has been flying by, and
many tasks have always pre-empted (personal/family related issues, paid work,
now some new GPL legal case drawing a lot of my attention, ...)

On Mon, Aug 16, 2010 at 09:55:39AM +0200, Andreas.Eversberg wrote:

> as you can see in the git log, i checked in the "ASSIGNMENT COMMAND"
> processing. it modifies timeslot, subslot, and hopping sequence. this is
> required when the network assigns an SDCCH before the actual TCH is
> allocated: after receiving the "ASSIGNMENT COMMAND", the layer2 is
> release locally (without sending anything), the dedicated mode is
> released and established with a new parameters (e.g. TCH/F), and the
> layer2 is established again, finally the "ASSIGNMENT COMPLETE" is sent
> to the network. this process is incomplete, but it should work in most
> cases. (no "starting time" processing).

this is (as usual) great news.  As part of my paid work I have to add
support for live frequency changes into OpenBSC anyway.  This means
the OML, RSL and 04.08 messages for changing the ARFCN of a given TRX
will all be synchronized by the same 'starting time' parameters.

I have no clue how well commercial GSM stacks in mobile phones implement
this feature, as a frequency plan change is something that happens so rare
in a regular network that you can probably afford to drop some calls once
you do it.

Once that work on OpenBSC is finished (I cannot provide a schedule yet),
we will be able to test the OsmocomBB side.

> in my local copy of the git, i already completed the assignment process.
> additionally "FREQUENCY REDEFINITION" is completed, "IMMEDIATE
> ASSIGNMENT" supports "starting time", MDL-error processing is added, and
> "HANDOVER COMMAND" parsing is done. the handover process is not
> completed, because it depends on unimplemented layer1 features, like
> RX-only channels or "4 successive HANDOVER ACCESS bursts on DCCH".
> except the handover process, the RR protocol for basic phone calls is
> complete now.

once again, great news.  handover support is important in the mid to long term,
but I think lots of other issues have a higher priority now (like SIM card
support, encryption, as well as reliable TS4..7 support)

> before i can check it in, it depends on two things. first, there are
> additional messages to be defined in osmocore:
> "[osmocore] Adding handover and frequency redefiniton message headers"
> http://home.eversberg.eu/osmocore.patch

I've finally committed that to libosmocore.git

> second, it depends on "starting time" support for layer1:
> http://home.eversberg.eu/modify.patch
> it adds a L1CTL message to store modified frequency allocations (ma,
> ma_len, HSN, MAIO, TSC) for hopping and a "starting time". this starting
> time is the frame number at which the modified frequencies are used. if
> the frame number lies in the past, the new modified frequencies are used
> after the L1CTL message is received. 

> sylvain already noted, that the event of "starting time" should be
> triggered by the scheduler. since i don't know how the scheduler exactly
> works, i would ask someone to change my patch. note that the dedicated
> mode can be released before the "starting time" elapses.

I'm sorry but I don't really think I'll have time to dig into this and modify
your patch anytime soon (in fact, I fear not throughout the next 2-3 months).

Using the scheduler should be relatively easy, you can simply call
sched_gsmtime() and provide it a framenumber and a 'tdma_sched_item'. the
latter will contain the callback that is to be called once the current
framenumber will reach 'fn' as specified.

I think that should be fairly straight-forward for you to try by yourself.
After it works, feel free to commit it to master.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)