1 Sep
2010
1 Sep
'10
11:41 p.m.
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)