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