hi,
today i will finally (begin to) structure the message handling in my
current work on layer 3:
the message handling functions consist of:
- message cration
- message sending
- message en-queueing
- message de-queueing
i deal with interfaces (SAP):
- between application and call control (MNCC-SAP)
- between call controll and mobility management (MMCC-SAP)
- between supplementary services protocol and mobility management
(MMSS-SAP)
- between sms protocol and mobility management (MMSMS-SAP)
- between mobility management and radio ressource (RR-SAP)
- between radio ressource and layer 2 / layer 1 (let's call it
RSLms-SAP)
additionally there are interfaces:
- between application and mobility management
- between application and PLMN search
- to the sim card
- to the application
- ...
here is what i think the messages should look like. please correct me if
i am wrong or if you have suggestions:
MNCC-SAP:
<gsm48_mncc structure>
MMCC-SAP, MMSS-SAP, MMSMS-SAP:
<gsm48_mmxx structure>[<L3 message*>]
RR-SAP:
<gsm48_rr structure>[<L3 message*>]
RSL-SAP:
<abis_rsl_rll_hdr structure>[<L3 message*>]
* the layer 3 message consists of the gsm48_hdr structure + additional
information elements.
if a layer 3 message moves from call control down to RSL and even lower,
the inter-layer headers are pulled and pushed. additionally there are
pointers to the beginning of the headers inside the message:
- l1h
- l2h
- l3h
- layer 4 headers
- layer 5 header
the inter-layer messages (MMxx-SAP and RR-SAP) will have no pointer to
the message structures. i think they also should not have them, since
they have fixed length and are pushed at the time they are sent, and
pulled at the time they are received.
any suggestions?
andreas
Hi,
First off, thank the community--OsmocomBB for launching and then sharing the
development of mobile protocol stack first.
As we can understand, the current mailing list has been acting as the
primary way of communicating between one another on the project basis.
For these quick questions as well as immediate discussions, however, most
likely there should be yet another way to complement, like irc on the
freenode.
Or, for the above issue you guys out there have other ways to solve, eh? If
so, please take me into the circle as well, just because I have too many
questions to ask. :)
Thanks.
Best Regards,
Samuel
> but found that the connection is extremely noisy.
> often the movement of me putting down the phone on the table is enough
> to break the upload.
i had a similar problem with an unconnected input pin which caused a
reset of a microcontroller, just by moving some centimeters in a
distance of one meter. check if you have left unconnected input pins on
your USB converter. what about hardware flow control input? (RTS/CTR)
andreas
hi harald,
>> must random value in chan_request change on every resend or only on
>> every RR establishment? (currently it changes on every RR
>> establishment only.)
>
>as far as I know, it has to change on every retransmission. Dieter is
>probably the person who knows all RACH aspects in detail, maybe he can
>comment on this.
from the specs it is quite clear that every access burst has different
random number when resending. but how does the network know if the burst
is from the same phone but retransmitted? in case of poor uplink many
bursts may be resent. will the network allocate a channel for every
burst received and waits for timeout? (if this is the case, emergency
calls could quickly 'evacuate' the cell.)
>> OpenBSC: if tx-msg fails during process, the msg must be freed to
>> avoid memory leak.
>
>I don't understand, can you please explain this further?
it is something to remind me that there are memory leak problems. in
some functions of gsm_04_08.c there are messages allocated at the
beginning and sent at the end. sometimes during processing, the function
returns due to error conditions, but the message is not freed before
return. i will check that later together with my new code.
as far as i can see right now, it just happens in gsm48_cc_tx_setup().
regards,
andreas
Hello Andreas,
On Mon, 29 Mar 2010 13:39:21 +0200, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote:
>
> from the specs it is quite clear that every access burst has different
> random number when resending. but how does the network know if the burst
> is from the same phone but retransmitted? in case of poor uplink many
> bursts may be resent. will the network allocate a channel for every
> burst received and waits for timeout? (if this is the case, emergency
> calls could quickly 'evacuate' the cell.)
It does not even need a poor uplink. I experience this behaviour for example
with OpenBSC and the nanoBTS. If the "Immediate Assignment" is not sent
fast enough, a retransmitted RACH burst will allocate another channel
(the timeout for releasing an unused channel is around 2 to 5 seconds in
"real" GSM networks). The maximum number of the retransmitted RACH burst
is controlled by a parameter in the SYSTEM INFORMATION messages (there
are several parameters which control the RACH transmission behaviour).
Of course a "bad phone" can ignore those parameters and a DoS attack
with continuous RACH bursts works quite well because the BTS or
network does not know from which phone the burst come from.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Christian,
On Mon, 29 Mar 2010 13:27:31 +0200, "Christian Vogel" <vogelchr(a)vogel.cx> wrote:
>
> I'm using a self-made cable consisting of a known good FT232R
> converter @ 3.3V and a cut off headset cable (that also worked
> flawlessly without any noise on another mobile phone before). My C123
> also looks pristine. I manage to upload and run hello world
> successfully in maybe one out of ten attempts, often have to remove
> the battery because the phone just gets stuck. So I have ordered a new
> cable from Akku-King as suggested on the Wiki.
My experience: I work under Windows with Cygwin so the OS internals
how the serial port is handled are (totally) different than Linux.
With the non-blocking variant of "osmocon" it was nearly impossible
to download the code to the phone in a reliable way. So I had to apply
an ugly hack to my version which basically switches the serial connection
to "blocking mode" during the download phase. This way it works rather
reliable here (regardless of using a "real" RS232 port or an USB to serial
converter).
So you might experience the same problem instead of a bad cable. You
can try the attached patch to "osmocom.c". The patch is not for the
latest GIT version, however it should be quite easy to apply it to
the current on. Again, its an ugly hack, but it works for me.
Best regards,
Dieter
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Willem,
On Mon, 29 Mar 2010 12:39:35 +0200, "willem" <itsme(a)xs4all.nl> wrote:
>
> but found that the connection is extremely noisy.
> often the movement of me putting down the phone on the table is enough
> to break the upload.
> is that a common problem with these headphone/serial cable plugs?
Hello Harald,
On Sun, 28 Mar 2010 13:16:36 +0800, "Harald Welte" <laforge(a)gnumonks.org> wrote:
>
> as far as I know, it has to change on every retransmission. Dieter is
> probably the person who knows all RACH aspects in detail, maybe he can
> comment on this.
According to the specification the random value has to change on every
transmission:
a random reference which is drawn randomly from a uniform probability
distribution for every new transmission.
In the TSM30 firmware this is done by having a table with random values
and an index into the table which is initialised to a random value when
the Immediate Assignment Procedure is started and incremented with every
random number taken for a retransmission. The table has 32 values because
the random reference is not larger than 5 bits.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi Andreas,
some comments regarding your issues.txt:
> must random value in chan_request change on every resend or only on
> every RR establishment? (currently it changes on every RR
> establishment only.)
as far as I know, it has to change on every retransmission. Dieter is
probably the person who knows all RACH aspects in detail, maybe he can
comment on this.
> must be expanded: struct osmocom_ms:
no problem here, expand it how you see fit. I just generally prefer
caller-allocated structures to callee-allocated ones, and I'd like to
use static allocation whenever possible. So if there's only one 'struct
rrlayer' per ms, then we should simply include 'struct rrlayer' as
sub-structure of 'struct osmocom_ms', rather than having two structures
and pointers between them.
> OpenBSC: if tx-msg fails during process, the msg must be freed to
> avoid memory leak.
I don't understand, can you please explain this further?
> random acces via RSL?
I think we simply add some new / non-standard primitives, as it does not
have any notion of RACH bursts.
It might also be possible to encode it as UNIT DATA REQUEST for channel
(chan_nr) RACH (CCCH uplink), but then we still cannot specify details
like at which frame number, etc. From what I can see, your
RSL_MT_RAND_ACC_REQ approach looks fine to me. As a minor improvement
we could call it RSLms_MT_RAND_ACC_REQ to indicate that it is our custom
RSLms message and nothing specified in the original RSLms spec.
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)
