This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgDear 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)