So far three persons have indicated their interest to join
a meeting at my place.
Considering the time it takes to drive to my place, it
probably makes sense to have the meeting at the weekend
(either Saturday or Sunday) so that there is more time
for the meeting itself. I can suggest one of the following
dates for the first meeting, somewhere between 10:00 to
18:00 on each day:
25.8. (Sa) or 26.8. (Su)
1.9. (Sa) or 2.9. (Su)
8.9. (Sa) or 9.9. (Su)
So please let me know when you have time and also make
suggestions in which Osmocom topic you are interested
in so that we can have some sort of agenda for the
meeting to make best use of the time.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello everyone,
I've just finnished writing together a small web interface for the OpenBSC
HLR. It allows you to modify various parameters in the database and also
provides a set of functions to modify the HLR or sending SMSes in your own
scripts.
The project is still very alpha but it seems to work reasonably good. Feel
free to give any feedback!
Screenshots and source code is available on my website:
https://stormhub.org/simplehlr/
--
*Best regards,
Peter Caprioli*
This is a Mailman mailing list bounce action notice:
List: OpenBSC
Member: fabrice.poundeu(a)smail.inf.fh-bonn-rhein-sieg.de
Action: Subscription disabled.
Reason: Excessive or fatal bounces.
The triggering bounce notice is attached below.
Questions? Contact the Mailman site administrator at
mailman(a)lists.osmocom.org.
Hi All,
as I've just been made aware of by a business contact, there is a
NEWSDR'13 workshop which, among other things, has OsmocomBB and OpenBSC
on the list of topics:
http://ecewp.ece.wpi.edu/wordpress/sdr-boston/newsdr-13/call-for-papers/
Did anyone ever hear of this workshop? Did the organizers ever make
contact with us? I'm a bit surprised that somebody organizes a workshop
with "our" projects on the agenda without even sending the CfP to us.
Or maybe I just missed it?
In case somebody is submitting a paper there: Please make sure to
coordinate here in order to avoid different developers/contributors from
submitting similar/related topics.
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)
I've never heard of either this workshop or the SDR Boston Listserv and
don't know any of the people on the organizing committee. One of the
moderators of the mailing list, which I just joined, is an EE professor at
Northeastern University, Miriam Lesser, who is well known in the FPGA
community.
Since I'm based in Boston, I'll plan to attend provided I'm not traveling
for my day job. If anyone would like to participate by proxy, please let
me know. [If I can get my act together in time, I may demo OpenBTS ported
to a Xilinx Zynq using the new Close-Haul GAPfiller RF front end.]
-Robin
Hello All,
Did anyone ever experienced such strange problems when downloading firmware into BS-11?
===
$ bs11_config
bs11_config (C) 2009-2010 by Harald Welte and Dieter Spaar
This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY
LMT LOGON: ACK
PHASE: 1 Software required Abis-link: Down
<0005> abis_nm.c:1196 Software Load (BTS 0, File "BTSBMC76.SWI")
Software Load Initiate ACK
===
...and then nothing happens for hours. I.e., no progress percentage, segment acknowledges, etc.
Does it mean that BTS is broken or something other?
Regards,
Sergey.
"Range Networks formally introduced today its executive management
team to deliver a complete open source software version of the
cellular system. Range Networks says it is the world’s leading
provider of American-made commercial open source cellular systems and
is slashing the cost to own and operate mobile networks."
http://www.dailywireless.org/2013/03/26/range-networks-open-source-cellular…
Hi,
I was discussing this crash[1] with Jan at the 29C3 and recently in
Iceland. On top of that Katarina pointed me to the best practises[2]
of talloc. In general I disagree with them[3] but they provide a nice
solution for the SGSN/MSGB ownership issue.
Methods that send a msgb should create a new local context and attach
it to a global context for all local contexts (so we see them in the
leak report). This would probably be done with a helper function in
libosmocore.
Once the msgb is created, we will steal it into the local context. Then
we pass it down the rabbit hole. Once it is reaching the write_queue it
is stolen back (or into a write queue context). The initial caller will
free his local context. And now there are three options:
a.) The msgb has made it into the write_queue.
b.) The msgb has been already deleted due to an error
c.) The msgb is still in the local context and will be freed.
Using the talloc_steal and the local context will make sure we do not
leak and do not double free. We can (and should) add a warning to see
under which circumstances the msgb has not been freed.
I think the implementation of this will be about 10-15 lines of code
(probably too optimistic).
comments?
holger
[1] http://openbsc.osmocom.org/trac/ticket/55
[2] http://talloc.samba.org/talloc/doc/html/libtalloc__bestpractices.html
[3] Most of our functions only allocate one object. There is no point
in having a hierachy of ROOT -> SingleObject. This indirection is
wasteful in most cases.
This is just a proposal how a scalable cost-effective solution can look
like. It is not implemented yet, but the goal is to work out a right
approach.
I developed quite similar things in 2003, when I interfaced ip.access BSC
to S-12 and AXE-10.
This is a piece of operator infrastructure, desired to be sold to MNO. In
Russia it also assumes certification procedure, held by authorized center.
On Mon, Mar 25, 2013 at 1:16 PM, John Wu <jwjohn0(a)gmail.com> wrote:
> Hi Dmitri,
> Have you developed the solution connect private GSM network to operator
> core network?
> But this should be allowed by the local operator, right?
>
>
> On Sat, Mar 23, 2013 at 5:09 PM, Dmitri Soloviev <dmi3sol(a)gmail.com>wrote:
>
>> Hi
>>
>> we've got several requests to extend existing GSM networks with our radio
>> equipment, where ip transport is appreciated.
>>
>> Please take a look at my vision of interfacing A-over-ip to a legacy GSM
>> A-interface.
>>
>> Building blocks:
>>
>> 1. OpenBSC with ip.access-compatible A-over-ip interface
>>
>> 2. MGCP-controlled transcoder, built with Sangoma D-series cards. Can be
>> assumed as a shared resource, available for several BSC instances.
>> http://www.sangoma.com/assets/docs/datasheets/en/d500.pdf
>>
>> 3. TelscaleSS7card - a stand-alone signaling and media gateway, with 2 E1
>> and 2 Ethernet interfaces, running embedded linux on board.
>> It converts A-over-ip to A-interface, acts as MGCP call agent for BTSs,
>> transcoders and other telscaleSS7cards. A card is implemented in PCI form
>> factor, but bus is used just to provide power supply.
>> In other words, a card can act either as a combined SG+MG, converting
>> A-over-ip into SS7 and RTP into E1 timeslot, or just a MG, converting RTP
>> into E1, without any impact on the host system.
>>
>>
>> When a [signaling gateway + call agent] detects ASSIGNMENT_REQUEST or
>> HANDOVER_REQUEST, it stores cic value. As soon as ASSIGNMENT_COMPLETE or
>> HO_REQ_ACK is detected, it builds RTP chain that unites
>> BTS<->transcoder<->media_gateway. The chain is broken after the call is
>> finished.
>>
>> Depending on the chosen cross plane, 4U 19" industrial PC can carry
>> several BSC instances with transcoding, serving about 20 E1 interfaces (ea
>> about 80 ARFCNs). Performance requirements for industrial PC cards are also
>> negligible: computer will run OpenBSC and configure transcoder cards, being
>> controlled by means of MGCP.
>>
>>
>>
>> Best Regards,
>> Dmitri
>>
>
>
Hi
we've got several requests to extend existing GSM networks with our radio
equipment, where ip transport is appreciated.
Please take a look at my vision of interfacing A-over-ip to a legacy GSM
A-interface.
Building blocks:
1. OpenBSC with ip.access-compatible A-over-ip interface
2. MGCP-controlled transcoder, built with Sangoma D-series cards. Can be
assumed as a shared resource, available for several BSC instances.
http://www.sangoma.com/assets/docs/datasheets/en/d500.pdf
3. TelscaleSS7card - a stand-alone signaling and media gateway, with 2 E1
and 2 Ethernet interfaces, running embedded linux on board.
It converts A-over-ip to A-interface, acts as MGCP call agent for BTSs,
transcoders and other telscaleSS7cards. A card is implemented in PCI form
factor, but bus is used just to provide power supply.
In other words, a card can act either as a combined SG+MG, converting
A-over-ip into SS7 and RTP into E1 timeslot, or just a MG, converting RTP
into E1, without any impact on the host system.
When a [signaling gateway + call agent] detects ASSIGNMENT_REQUEST or
HANDOVER_REQUEST, it stores cic value. As soon as ASSIGNMENT_COMPLETE or
HO_REQ_ACK is detected, it builds RTP chain that unites
BTS<->transcoder<->media_gateway. The chain is broken after the call is
finished.
Depending on the chosen cross plane, 4U 19" industrial PC can carry several
BSC instances with transcoding, serving about 20 E1 interfaces (ea about 80
ARFCNs). Performance requirements for industrial PC cards are also
negligible: computer will run OpenBSC and configure transcoder cards, being
controlled by means of MGCP.
Best Regards,
Dmitri