Hello Harald,
On Mon, 2 Nov 2009 22:47:18 +0900, "Harald Welte" <laforge(a)gnumonks.org> wrote:
>
> This is actually very funny. According to the protocol, a RA update should
> only be performed if the MS was/is already GPRS ATTACHED to this network
> before. It clearly wasn't in this case, as the OpenBSC network never
> offered GPRS support. Still, it tries it. That's why we're rejecting it.
Not sure if I understand it in detail, from my understanding an RA Update
is performed when the Routing Area has changed (or the periodic RA update
timer has expired). So if the phone is already attached to a network,
shouldn't we receive the RA update if it selects our new RA ?
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello,
I never used it much, but when I try to send an SMS
from a MS to another one it is not delivered to the second MS.
OpenBSC displays that the SMS was received.
If I do a Location Update on the second Phone the SMS gets delivered.
Also if I enter the command "sms send pending".
How can I setup automatic delivery?
Am I right, that OpenBSC first looks, if the second subscriber is
connected
to the network and then delivers the message?
regards
Bjoern
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Björn Heller
Jabber: tec(a)jabber.hellercom.de
Hi!
Since the current two main developers of OpenBSC (Holger and myself) are
travelling almost all the time and not in the vicinity of a BS-11, I fear
that we sometimes might introduce code that is incompatible with the BS-11
or introduces regressions on it.
Threfore, I would like to see if there are any volunteers here who are willing
to regularly check out the latest code and test it if it still works on their
BS-11.
Anyone?
Thanks in advance,
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)
Got it ;)
Voice-calls working.
Thanks everyone!!!
Best Regards
Björn Heller
Am 05.11.2009 um 13:02 schrieb Holger Freyther <zecke(a)selfish.org>:
> On Thursday 05 November 2009 12:50:32 Bjoern Heller wrote:
>> Ok, found the BTS, but
>> in ipaccess config I get a "no matching signalling link for hh-
>>
>>> proto=0xff" back. I used the command from the wiki...
>
>
> update the source? I fixed that last week.
>
> z.
>
>
Hello everybody!
Got my ip.access today by mail! *happy.
Is there any configuration tool for it?
Or how do I configure it to listen on an specific IP?
Best Regards
Björn Heller
Hello Sylvain,
On Tue, 03 Nov 2009 07:03:15 +0000, 246tnt(a)gmail.com wrote:
>
> Initially I had a segfault when receiving a GMM ATTACH. The MCC/MNC in the
> CELL ID transmitted in the GMM ATTACH REQUEST are not the one I set in
> openbsc.cfg, they seem hardcoded to 001/01 but I haven't found from where
> yet. So currently you need to set 1/1 in your openbsc.cfg as well.
Its in bsc_init.c, the variable "nanobts_attr_bts":
NM_ATT_IPACC_CGI, 0, 7, 0x00, 0xf1, 0x10, 0x00, 0x01, 0x00, 0x00,
I did modify patch_nm_tables() and added:
// this overwrites nanobts_attr_bts[54], but we set it later anyway
gsm48_ra_id_by_bts(&nanobts_attr_bts[49], bts);
nanobts_attr_bts[54] = htons(bts->cell_identity) & 0xFF;
nanobts_attr_bts[55] = (htons(bts->cell_identity) >> 8) & 0xFF;
Additionally I fixed setting the BSIC:
nanobts_attr_bts[45] = bts->bsic;
I have not yet provided a patch because its not fully tested,
however Harald is informed.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Sylvain,
On Mon, 2 Nov 2009 01:05:20 +0100, "Sylvain Munaut" <246tnt(a)gmail.com> wrote:
>
> I found out the problem.
>
> In gprs_bssgp_tx_dl_ud, then length encoded in the PDU TLV is
> incorect. It uses msg->len but at that point it already did a
> msgb_push to add space for the header so msg->len is already too big.
> You need to save the size of msg->len before the msgb_push and then
> use that when encoding the PDU TLV length.
Thanks for the info, I tried it here but it did not help for the
"GMM ATTACH REQUEST", the nanoBTS still reboots when it receives
the data of the "GPRS IDENTITY REQUEST" which is sent afterwards.
I finally found the reason for this behaviour (at least I hope
it is the reason), I had to specify the correct BVCI parameter
for the call to gprs_ns_sendmsg() in gprs_bssgp_tx_dl_ud(). If
I use "925" instead of "0" it works. The phone sends an "GMM
IDENITY RESPONSE" and continues to send "GMM ATTACH REQUEST"
because it does not yet receive an accept.
> BTW, do you sometimes hangout in #openbsc ?
No, usually not (its a bit difficult for me to do my work and
look at what is happing on IRC).
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Dear Tim!
I hope you don't mind I'm Cc'ing the mailing list. This means that other
people can get involved in the discussion - and also means that I only
have to write my summary about what needs to be done once, even if you
for some reason are unable to complete the actual implementation :)
On Mon, Nov 02, 2009 at 01:25:13PM -0500, Newman, Timothy wrote:
> I'm working at Virginia Tech and it looks like we are going to start playing
> with the cell broadcast gsm stuff. I'd like to just go ahead and add it into
> openbsc.
This is great news, thanks. Which BTS type are you using with OpenBSC?
> Other than the brief read through of some of the 3GPP documents related to
> cell broadcast, I'm not too familiar with the interworkings of it.
It's not really difficult. What needs to be done
1) enable a channel configuration that adds a CBCH to one of the SDCCH/4 in
a combined CCCH, or one of the SDCCH/8. I'd prefer the SDCCH/4, since
that is supported by both BS-11 and nanoBTS. However, feel free to implement
both options
2) encode the CBCH message (very similar to SMS encoding) TS 03.38 / 03.41
3) have a function to send the CBCH to the BTS over RSL (TS 08.58)
4) later: Implement the Scheduling (Chapter 2.1 of TS 04.12) for DRX
There's two options for cell broadcast:
1) you can set a default cell broadcast message once by the BSC. The BTS then
transmit that CB in every idle fame of the CBCH (TS 08.58 SMS BROADCAST CMD)
2) you want to sent multiple different CB messages, then the BSC needs to do
the scheduling and send them to the BTS's (TS 08.58 SMS BROADCAST REQ)
> I'm a little unclear how long this may take to add this functionality into
> openbsc. If you had to estimate how long it would take (e.g. 1, 2, 6, 12
> months), what would you say? Just give me your estimate and I'll multiply
> this by 4 because it will be students working on the project and they need a
> little (a lot) of ramp of time for this also.
If I or any other of the OpenBSC developers was doing it, I would say this is a
matter of days, one week max for all of the options described above. However,
you need to consider that your studends also have to read up the 3GPP specs,
are unfamiliar with the terminlology, don't know the OpenBSC codebase, probably
have not that much experience with "plain C" programming in an select-loop single
threaded design, ... so a factor of four might not be sufficient.
Regards,
Harald
p.s.: I would be interested in learning what you're using OpenBSC for at
Virginia Tech. If you have a minute to elaborate on that, I'm very curious.
Other people on the mailing list might share that interest, especially those
users from academic institutions. If you prefer to respond privately, that
would also be OK with me.
--
- 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)
Special offer for the last nanoBTS type 139,
Siemens (MOGIS) branded, new in box, but without POE-Adapter!
Only one available, only 1900 Euro plus shipment.
Contact me at womax(at)gmx(dot)ch
Hello Sylvain,
On Sun, 1 Nov 2009 21:17:26 +0100, "Sylvain Munaut" <246tnt(a)gmail.com> wrote:
>
> - In gprs_bssgp.c the function bssgp_rx_ul_ud calls :
>
> bts = gsm48_bts_by_ra_id(
> TLVP_VAL(&tp, BSSGP_IE_CELL_ID),
> TLVP_LEN(&tp, BSSGP_IE_CELL_ID));
>
> But gsm48_bts_by_ra_id defined in gsm_04_08_gprs.c takes 3 arguments
> the gsm_network as first one then the buffer and lenght. Since the
> function was implicitely defined in gprs_bssgp.c, it compiled but of
> course segfaulted as soon as it got there ... I don't even understand
> how it worked for you.
At the time I made the trace, I did not yet have connected with a GPRS
phone. In the meantime I made a temporary workaround by referencing
the global "bsc_gsmnet" and using it for the first parameter.
> <0004> gsm_04_08_gprs.c:434 GMM RA UPDATE REQUEST type="RA updating" REJECT
> <0004> gsm_04_08_gprs.c:408 <- ROUTING AREA UPDATE REJECT
>
> But as soon as the REJECT is sent to the BTS, it reboots ... no error
> no message nothing ...
I get a "GMM Attach Request" with my phone and the same behaviour
afterwards, the nanoBTS reboots.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
