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)