hi!
we now have a 'struct timer_list' API, its use is similar to that of
the linux kernel (and openbsc).
The caller (e.g. your driver/app) allocates a 'struct timer_list', sets
the 'cb' function pointer to a callback function, and then schedules the
timer with 'schedule_timer(&my_struct_tm, 600) for expiration in e.g. 600ms
from now.
Once the timer expires, it will call the callback. There's also an
'unsigned long' argument that you can pass along.
Calling the timer expiration routines happens by calling update_timers() from
the while (1) loop in the main program. This will of course change once
we have a scheduler and tasks.
Cheers,
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)
> L3 sends RSL RLL ESTABLISH REQUEST with LOC UPD REQ as L3_INFO
> L2 converts this in SABM with LOC UPD REQ as payload
> L1 sends the packet to the GSM network
> L1 receives response from the GSM network
> L2 generates RSL RLL ESTABLISH CONFIRM to L3
hi,
just to see if i understand it right, here is my view of how it should
work:
(for reference, see Fig. A.4 in GSM 04.07 in the appendix A.)
mobility management layer requires to send an location update, so it
does the following things happen:
- a msgb is created with payload, large enough for LOC UPD REQ, and a
headroom to encapsulate it into other messages...
- LOC UPD REQ is assembled by mobility management layer
- the msbg is "pushed" to add radio ressource header in front of it
- the radio ressource primitive RR EST REQ is written to radio ressource
header
- the msgb is now transferred using a function call to radio ressource
layer
- the radio ressource routes the message according to the state and the
primitive to the appropiate handler of this message. (state machine)
- there the msgb is "pulled" to remove that header
- the handler of "RR EST REQ message in IDLE mode" stores the msbg until
an IMM ASS is received, and starts channel request procedure...
...
- when handling the IMM ASS, the radio ressource layer takes the stored
msgb and pushes the RSL RLL header in front of it
- the RSL RLL header gets informations about channel to establish, and
the RSL EST REQ primitive is set
- the msgb is sent down from radio ressource layer to layer 2, in this
case the RSLms layer, using a function call.
(RSL EST REQ represents the DL-ESTABLISH REQUEST primitive)
while the message is walking from radio ressource layer down to layer 1,
the primitives for inter-layer communication are added by the sending
layer and removed by the receiving layer.
is this procedure correct? (of course, more things are done at radio
ressource and mobility management layers in the procedure above, but i
just wanted to explain what happens to the msgb.
regards,
andreas
hi,
my last mail was written yesterday and somehow sent today.
meanwhile i decided to work with GIT for the following reasons:
- working with others parallel on L3
- faster solving of issues. solving before finishing the code.
- backup (even loss of one weekend's work would be a great loss of
motivation)
i will try the GIT tonight...
anyway here is my first issue:
the messages between layer 3 (radio ressource) and layer 2 have
primitives starting with DL_*.
e.g. DL_RANDOM_ACCESS_REQ is used to send a CHANNEL REQUEST on the RACH.
and DL_ESTABLISH_REQ is used to establish a layer 2 link on SDCCH or
TCH.
both messages carry layer 3 messages, like CHANNEL REQUEST or LOCATION
UPDATE REQUEST. using msgb between layer 2 and 3 is not enough, because
i need to exchange additional informations with layer 2. these are the
primitives themselves, and in case of DL_ESTABLISH_REQ the channel
information for frequency, channel type, slot, ect.
my current solution is to use a structure with primitive type and all
additional informations and a pointer to the attached layer 3 message,
if there is actually one message. (not yet immplemented, but already
implemented at mncc interface in openbsc.)
to prevent function call loops, i use a queue in the upward direction,
so the structure with the message is copied into a msbg and added to the
queue. (remember that this message may carry another layer 3 message)
is there a better (simpler) way?
regards,
andreas
hi harald,
as i am still working on RR MM and CC layer, it seems to be more complicated as i thought. remember all the messages in 04.08? but most problem is that i must first understand it all. i get more and more knowledge about it while reading it. i started implementing some parts, but most parts i do not understand yet. as i know from earlier project, it requires exact knowledge of every bit to do it right.
when i am finished, i will tell you as soon as possible, but i think it takes some more weeks. anyway, there will be many issues then. as i can see, there the layer 2 and layer 1 will also be not that easy too. e.g. layer 2 must process channel descriptions to connect to the right channel and the right configurations and mode. also when i am finished, i will need to solve some coding issues, like message flow, queueing (to prevent message loops), and structures for subscriber data, telephone settings and system informations. as soon i am finished, i will make a list of remaining unsolved issues.
and finally gsm 03.22 (selecting and changing cells) must also wants to be implemented.
if you like to be aware of what i am doing, just watch my code base. it is live, so every time i do a write, it will be available at: http://home.eversberg.eu/alpha3/
regards,
andreas
Hi!
Today, there have been quite a number of possibly intrusive changes in
the repository. A quick summary:
* prom's new makefile voodoo has been merged for the 'firmware' directory,
this means we now have proper dependency tracking in our builds, as well
as support for multiple board builds
* the compiled elf/map/bin/... files are now in board/compal_{e88,e99},
rather than in the main directory.
* the firmware now uses the real libosmocore (and its linuxlist, msgb,...)
code. No more code duplication, and one step closer to easy migration
of the layer23 code into the firmware at some later day.
* lots of minor changes here and there have been introduced to reduce number
of compiler warnings.
* l1ctl messages (L1 <-> L2/L3) communication has changed a little bit,
it now includes only the frame number and not a full 'struct gsm_time'.
This is important for anyone who has his own ocde to talk to the L1!
I hope this was the last time we've had such an amount of changes, especially
to the build system.
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)
Hi Steve,
I have now partially merged your C155 display driver. Partial, since
I only merged those parts that didn't break the build for C123.
So what needs to be done soon:
* support multipe 'boards' in our Makefile magic, producing NR_BOARDS * NR_APPS
images as a result.
* merge those parts that are identical between board_e88 and board_e99
and create something like a calypso_init() function, keeping only board
specific bits in the board_init()
* introduce some "lcd_puts()" macro that is defined to either of the two
display drivers, depending on the board that we're building for.
If anyone is posting patches (or a git branch) for that, I'd be happy to merge
them.
Later on, I want a LCD abstraction layer that hides the details from
the apps. The app should not have to care about color/monochrome, or the
fact that the X/Y coordinates seem to be inverted between the displays.
I personally have no interest in doing that, as GSM related work has much
higher priority to me. I hope somebody in the community will take care of the
task. Thanks in advance!
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)
Hi Andreas,
I'm going to pick up your questions as found in your preliminary
http://home.eversberg.eu/alpha3/ code.
I took the liberty of posting to the ML, as other people will definitely
be interested in this, too.
1) why is layer2 a socket client?
because we want to develop layer2 + layer3 + everything above on the PC first,
while keeping the L1 on the phone. This makes debugging much easier. Later
we will simply move the code to the phone and run it in one or multiple
tasks of the operating system, replacing sercomm + unix socket with message
queues.
2) where is layer3 to go?
I think we can directly put it into the layer2 program, but try to keep a clean
seperation between l2 and l3, using the REQUEST/RESPONSE/INDICATION primitives.
3) where should the app (layer4) go? library or console?
it should live on top of the l23 stack, preferrably as its own program.
There is a lot of sense for having the application (UI) as its own
process/thread, and the stack in its process/thread.
4) Is the TLV parser buffer-overflow safe?
TLV parser (libosmocore) is not buffer-overflow safe, patches are appreciated.
5) classmark1 lsb/msb twisted:
I have no idea :)
6) lchan/ms mapping.
I don't have a clear idea on this either. I'm not so sure if the 'lchan'
concept makes much sense in a phone at all. A phone typically only uses one
dedicated channel at any given point - with corner cases in the event of a
handover, where we 'switch back' to the old channel if establishing the new
channel fails.
7) ms instantiation for multiple devices
I think this is not really an important issue at the moment. If there are
multiple phones, there should be multiple instances (processes) of the layer23
stack. A normal application would also exist 1:1 for each stack instance.
If you think of some PBX application, than I also think it is easier to have
one instance (process or thread) of the stack for each phone.
After all, the primary target for us is to make layer2+3 work in a phone,
and there it will definitely be one instance for one phone.
One additional comment:
Please make sure that the common/shared code between OpenBSC and your Layer3
does get moved into libosmocore. I'm thinking particularly abotu code for
parsing and generating the various IE's. We don't want to keep multiple
implementations around...
Thanks again for all your help,
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)
Hi!
There will be an informal meeting of OsmocomBB hackers at the Berlin CCC
(http://berlin.ccc.de/) on Saturday, 2010-03-06 at 8pm local time.
Prom and myself will be there, most likely also dexter and tec. If you're
local, feel free to join.
There's no formal agenda, we just like to meet one more time before I'll
disappear to Taiwan for quite some time.
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)
Hi!
I've improved the layer23 gsmtap support to add support for
* uplink frames, sent by layer23 to L1
* properly support dedicated channels with LAPDm
* allow the user to specify the GSMTAP destination IP address
In order to use the new features, you need to
1) use the new gsmtap.patch for wireshark
2) use the '-i dstip' option of layer23, as the default is now to NOT
generate GSMTAP UDP Packets
I'm attaching a screen-shot showing the wireshark decode of the LOC UPD REQ
generated by layer23. As you can see from the packet list, the BTS responds
with the UA packet containing the same LOC UPD REQ as part of the contention
resolution in LAPDm, just as expected.
Cheers,
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)
