OpenBSC: Newshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092017-06-24T18:45:57ZOpen Source Mobile Communications
Redmine Lab Update: OsmoMSC Serves 2G + 3G for the First Timehttps://osmocom.org/news/742017-06-24T18:45:57Zneelsnhofmeyr@sysmocom.de
<p>Yesterday we've reached a remarkable milestone: the new OsmoMSC has first subscribed a 3G <strong>as well as</strong> a 2G phone at the same time!</p>
<p>Recall the recent big developments in Osmocom:</p>
<ul>
<li>creating OsmoHLR to manage subscribers asynchronously and across voice and data realms,</li>
<li>separating an OsmoMSC off OsmoNITB,</li>
<li>creating a true asynchronous state machine driven VLR in OsmoMSC,</li>
<li>adding UMTS authentication with Milenage,</li>
<li>supporting IuCS (and IuPS) to enable hNodeB driven 3G in Osmocom,</li>
<li>and last but not least adding a true A interface to OsmoMSC using our brand new SCCP/M3UA impementation.</li>
</ul>
<p>After this work has reached a stage where we can subscribe phones, send SMS and call each other using AoverIP and 3G separately, the remaining big step was to combine all of this in <em>the</em> new OsmoMSC: can we talk both A over IP to our separate OsmoBSC as well as IuCS via OsmoHNBGW to a 3G hNodeB, <em>at the same time</em>?</p>
<p>Some patches are still in the queue, but since yesterday, the answer is a resounding: Yes!</p>
<p>Typical for a software engineer's mindset, the joy of reaching this milestone is immediately followed by an outlook of what is left open:</p>
<ul>
<li>Split the current / legacy openbsc.git repository in separate new projects and lay the OsmoNITB to rest.</li>
<li>Rename our MGCP gateway (osmo-bsc_mgcp) to OsmoMGW and teach it to transcode between TRAU frames, RTP and the 3G IuUP to facilitate voice calls between all of legacy BTS models using E1, our "current" 2G BTSes talking RTP over IP as well as 3G hNodeBs that encapsulate IuUP in RTP.</li>
<li>Polish to production quality, update the docs and package for various platforms.</li>
</ul>
<p>These are exciting times to be part of Osmocom: big changes are finally converging, to open up new horizons for FOSS driven cellular network technology.</p> 3G Voice Workshttps://osmocom.org/news/592016-10-03T14:25:56Zneelsnhofmeyr@sysmocom.de
<p>I am glad to announce that we have succeeded in placing a 3G voice call between<br />two phones using an hNodeB cell and the Osmocom 3G core network. Find attached<br />a full network trace including IuCS signalling as well as the RTP voice stream.<br />This, proudly, is the first publicly available pcap of Iuh, IuCS and IuPS, and<br />it was created using exclusively free software in the core network stack.</p>
<p>The Osmocom 3G stack is being developed at <a href="https://sysmocom.de" class="external">sysmocom</a>, supported by highly<br />appreciated sponsoring from <a href="https://nlnet.nl" class="external">NLnet</a> and sysmocom customers -- thank you for<br />making this possible!</p>
<p>Osmocom has had 3G data connectivity working for some months now<sup><a href="#fn3">3</a></sup>, and the<br />IuPS code has already been merged to OpenBSC's master branch (though it still<br />requires libosmo-netif, libosmo-sccp and asn1c to be built from the branches<br />indicated below).</p>
<p>The 3G voice counterpart is taking somewhat longer, not because it's more<br />difficult per se, but mostly because it needs profound refactoring of our MSC.<br />So far our MSC was closely tied to the BSC code, and to include IuCS, we need to<br />separate them.</p>
<p>Are we done with 3G now? Not quite. Things need to be made fully configurable,<br />proper 3G authentication needs to be integrated, and all work needs to be put in<br />a stable release. We would also like to have a proper 2G A interface as a<br />companion to the 3G IuCS interface, which would allow us to completely replace<br />the OsmoNITB with the new OsmoCSCN.</p>
<p><em>NOTE from the future: OsmoCSCN has since been renamed to OsmoMSC!</em></p>
<p>Read this as a humble invitation to join NLnet<sup><a href="#fn1">1</a></sup> and other sysmocom customers<br />in funding the open source 3G core network development here at sysmocom<sup><a href="#fn2">2</a></sup>.<br />The resulting software stack is free for everyone, including you, both in the<br />sense of free speech as well as the proverbial free beer, and we can still use<br />all the support we can get to wrap this up. If you would like to see this working<br />sooner rather than later, do not hesitate to contact us<sup><a href="#fn2">2</a></sup>.</p>
<p>So, we're still working on Osmocom 3G, but if you would like to take a look<br />ahead, here is how:</p>
<p>We have a 3G authentication implementation ready, but since this is not yet<br />integrated in our HLR/VLR and MSC libraries, we're still working with hardcoded<br />2G authentication tokens. So to test, you still need specially provisioned SIM<br />cards. Firstly, they must be incapable of 3G authentication, so that the phone<br />decides to fall back to 2G auth. Secondly, they must all be programmed with a<br />Ki of <code>000102030405060708090a0b0c0d0e0f</code>. If you need help here, feel free to<br />contact us<sup><a href="#fn2">2</a></sup> -- we're in the meantime working on integrating full 3G<br />authentication with osmo-cscn and osmo-sgsn.</p>
<p>To set up a 3G core network based on free Osmocom software, this is what you<br />need:</p>
<pre>
+--------+
,-->| MGCPGW |<--RTP--...
/ | |
| | |<--MGCP
| +--------+ \
/ |
+------------+<--RTP +--------+ `->+----------+
UE <-->| hNodeB | | HNB-GW | | OsmoCSCN |
UE <-->| |<--Iuh---->| |<--IuCS-->| |
| | ...-->| | ...-->| |
| | | | +----------+
+------------+<--GTP-U | |
\ | | +------+ +------+
| | |<--IuPS-->| SGSN |<--GTP-C-->| GGSN |
| +--------+ ...-->| | GTP-U-->| |
| +------+ / +------+
\_______________________________/
</pre>
<p>Instead of a traditional NodeB, we use "smaller" hNodeB 3G cell hardware to take<br />care of the radio interface. This has the advantage that it already has an RNC<br />integrated, which we would otherwise need to implement separately. The RNC will<br />talk Iuh, i.e. HNBAP and RANAP<sup><a href="#fn4">4</a></sup>, to OsmoHNBGW running on your box, let's call it<br />the core network computer (CN).</p>
<p>Besides the HNB-GW, your CN further comprises of OsmoCSCN for voice signalling<br />as well as the OsmoMGCPGW to direct RTP streams. For data, there are OsmoSGSN<br />and OpenGGSN.</p>
<p>In short, Iuh is the combined voice (IuCS, Iu circuit switched) and data (IuPS,<br />Iu packet switched) signalling, which the HNB-GW splits to OsmoCSCN (circuit<br />switched core network) and OsmoSGSN. When a phone (UE, user equipment) starts<br />a call, OsmoCSCN takes care of all the signalling, from authentication to RAB<br />assignment, and instructs the MGCPGW to forward the RTP streams from the hNodeB,<br />in our case, back to the same hNodeB and to the other UE. In the field, the<br />MGCPGW would instead forward to a remote media gateway.</p>
<p>To set up your CN, build and install the following projects from<br /><a class="external" href="http://git.osmocom.org">http://git.osmocom.org</a>, using below branches; the current state of which have<br />also been tagged as '3G_2016_09':</p>
<ul>
<li>libosmocore: master <a href="http://git.osmocom.org/libosmocore/tag/?h=3G_2016_09" class="external">9c0751fc60e6282b5f5ff791d53f6f862f1c9c79</a></li>
<li>libosmo-abis: master <a href="http://git.osmocom.org/libosmo-abis/tag/?h=3G_2016_09" class="external">15d9b7929d449e4138bcb003c614035bceadc3d1</a></li>
<li>libosmo-netif: sysmocom/sctp <a href="http://git.osmocom.org/libosmo-netif/tag/?h=3G_2016_09" class="external">b830719b392dc96fd7987fb3dfba31a92a6fa38b</a></li>
<li>libosmo-sccp: sysmocom/iu <a href="http://git.osmocom.org/libosmo-sccp/tag/?h=3G_2016_09" class="external">c1307ee64d25f4b19397bcf4791ba4c85d1dbe79</a></li>
<li>libsmpp34: master <a href="http://git.osmocom.org/libsmpp34/tag/?h=3G_2016_09" class="external">2ccf5304ca465fbc70f6ae3283b4f49aaa9b650f</a></li>
<li>asn1c: aper-prefix-onto-upstream <a href="http://git.osmocom.org/asn1c/tag/?h=3G_2016_09" class="external">b9b7c9e54d079c6093a5e77a79aabed409dc9bfb</a></li>
<li>libasn1c: master <a href="http://git.osmocom.org/libasn1c/tag/?h=3G_2016_09" class="external">20d668cbd3c14ef32fcbd09617fbd3c8e6856ec0</a></li>
<li>osmo-iuh: master <a href="http://git.osmocom.org/osmo-iuh/tag/?h=3G_2016_09" class="external">f41b2fa500c209136c3446f4bc9d9da348539f92</a></li>
<li>openggsn: master <a href="http://git.osmocom.org/openggsn/tag/?h=3G_2016_09" class="external">03dbafb000c88155309dfd67b3bba73f7b389e69</a></li>
<li>openbsc: sysmocom/iu <a href="http://git.osmocom.org/openbsc/tag/?h=3G_2016_09" class="external">8a9f12dc2f69bf3a4e861cc9a81b71bdc5f13180</a></li>
</ul>
<p>Once the CN stack is built, set up the configuration. Find attached files for an<br />example of a local test setup. Some details explained:</p>
<p>Tell the osmo-hnbgw which local IP address to use to listen for Iuh connections.<br />This needs to be on an interface reachable by the hNodeB. The IuCS and IuPS<br />links towards the osmo-cscn and osmo-sgsn are so far still hardcoded as<br />127.0.0.1 and 127.0.0.2, respectively, i.e. osmo-cscn and osmo-sgsn should run<br />on the same machine as the osmo-hnbgw. These will listen on the proper port<br />without further configuration (still hardcoded).</p>
<p>Also tell the MGCPGW (osmo-bsc_mgcp) which local IP address to bind to, which<br />has to be reachable both by the hNodeB as well as the osmo-cscn process. The<br />osmo-cscn.cfg is then told where to reach the MGCPGW.</p>
<p>A notable detail for 3G data is that the GGSN has to be reachable by the hNodeB.<br />Since the GTP standard defines fixed port numbers which both SGSN and GGSN have<br />to to use, the SGSN may not bind on the same IP address as the GGSN.</p>
<p>Once you have configured the IP addresses, start up your core network: launch<br />osmo-cscn, osmo-bsc_mgcp, osmo-sgsn, ggsn and osmo-hnbgw. You should see log<br />messages indicating established IuCS and IuPS links (HNBGW, CSCN and SGSN).</p>
<p>With your CN up and running, configure the hNodeB to contact osmo-hnbgw. Also<br />make sure the PLMN ID and LAC are configured correctly, to match the MCC and<br />MNC in the osmo-cscn.cfg -- otherwise the hNodeB may reject all attach requests.<br />Finally, do authorize the SIM card's IMSI, e.g. using osmo-cscn's telnet VTY,<br />and if necessary configure the hNodeB to allow access by this IMSI.</p>
<p>The attached pcap file contains a complete network trace of:</p>
<ul>
<li>HNBAP of hNodeB registering at the HNB-GW;</li>
<li>two UEs registering first at the HNB-GW (HNBAP UE Register) and then on IuCS<br /> and IuPS (MM Location Updating, GMM Attach), coming in via Iuh at the HNB-GW<br /> and forwarded to OsmoCSCN and OsmoSGSN;</li>
<li>the two UEs browsing the websites nlnet.nl<sup><a href="#fn5">5</a></sup> and the current xkcd webcomic,<br /> with PDP Context allocation as well as GTP-C and GTP-U<sup><a href="#fn6">6</a></sup>;</li>
<li>a voice call where the one UE calls the other (i.e. MO with Service Request to<br /> MT with Paging), with the RTP stream directed through our MGCP GW using CRCX<br /> and MDCX instructions;</li>
<li>each UE sending an SMS to the other.</li>
</ul>
<p>The IP addresses used in attached network trace are:</p>
<ul>
<li>10.9.1.11: hNodeB 3G femto cell;</li>
<li>10.9.1.120: CN computer's interface for Iuh and RTP, as well as the SGSN's<br /> GTP-C side towards the GGSN;</li>
<li>10.9.1.13: CN computer's interface for GTP-U towards the hNodeB as well as<br /> GTP-C towards the SGSN<sup><a href="#fn7">7</a></sup>;</li>
<li>127.0.0.1: loopback on the CN computer for IuCS;</li>
<li>127.0.0.2: loopback on the CN computer for IuPS;</li>
<li>10.23.42.*: IP addresses given to UEs within the GTP tunnel;</li>
<li>all other IP addresses are remote servers contacted by the UEs.</li>
</ul>
<p>When looking at network traces, note the various protocols: Iuh, IuCS and IuPS<br />communicate via SCTP (as opposed to TCP or UDP). You will see the same Iu<br />messages twice<sup><a href="#fn8">8</a></sup>, e.g. once on IuCS between HNB-GW and CSCN, encapsulated in<br />RANAP/SUA<sup><a href="#fn9">9</a></sup>, and again on Iuh between HNB-GW and hNodeB, encapsulated in<br />RANAP/RUA. In contrast, the MGCP configuration and RTP streams for voice use<br />UDP, and so do GTP-U and GTP-C for the data link.</p>
<p>In conclusion, we still need some work to reach our goal of a fully operational<br />3G core network. The attached trace of a 3G voice call using exclusively free<br />Osmocom software proves that we are now very close indeed.</p>
<p>We invite you to test and use our 3G core network stack, and if you can,<br />consider joining NLnet and sysmocom as sponsor of the ground breaking work in<br />the Osmocom community.</p>
<p><em>Edit: see also [[Cellular Infrastructure:Getting Started with 3G]]</em></p>
<hr />
<p id="fn1" class="footnote"><sup>1</sup> NLnet foundation, <a class="external" href="https://nlnet.nl">https://nlnet.nl</a></p>
<hr />
<p id="fn2" class="footnote"><sup>2</sup> sysmocom systems for mobile communications GmbH, <a class="external" href="https://sysmocom.de">https://sysmocom.de</a> / <a class="email" href="mailto:info@sysmocom.de">info@sysmocom.de</a></p>
<hr />
<p id="fn3" class="footnote"><sup>3</sup> <a class="external" href="http://osmocom.org/news/30">http://osmocom.org/news/30</a></p>
<hr />
<p id="fn4" class="footnote"><sup>4</sup> See also this <a href="https://git.osmocom.org/osmo-iuh/tree/doc/protocols_around_hnbgw.txt?id=a44cb48c4656b30d80f4e165c33598d3f8e6e32c" class="external">protocol stack diagram</a></p>
<hr />
<p id="fn5" class="footnote"><sup>5</sup> nlnet.nl is browsable by https only, so all you see is TLS encrypted data.<br />I would have liked to see a DNS query for nlnet.nl, but the UE had already<br />cached its resolution to 193.200.132.212. There are, however, other DNS queries,<br />as well as a plain http session for xkcd.com.</p>
<hr />
<p id="fn6" class="footnote"><sup>6</sup> I have, for privacy reasons, filtered from the pcap some services that the<br />UEs eagerly contacted but which were not browsed explicitly during the test.</p>
<hr />
<p id="fn7" class="footnote"><sup>7</sup> It is however possible that few GTP-U packets end up at the SGSN between<br />activating the PDP context and redirecting GTP-U towards the hNodeB's address,<br />which can only be known after the IuPS RAB Assignment is complete.</p>
<hr />
<p id="fn8" class="footnote"><sup>8</sup> Note that the timing differences between the internal loopback and eth0<br />interfaces may cause their ordering to appear slightly out of sync in the pcap.</p>
<hr />
<p id="fn9" class="footnote"><sup>9</sup> RANAP/SUA is our non-standard choice of SIGTRAN for IuCS and IuPS, since it<br />has simpler layering than the standard RANAP/SCCP/M3UA. See also<sup><a href="#fn4">4</a></sup>.</p>
<hr /> OsmoDevCon from March 27 through March 30, 2015 https://osmocom.org/news/282016-02-21T12:22:17Zlaforge
<p>Dear fellow Osmcoom developers,</p>
<p>it is my pleasure to finally announce the date + venue of <a class="wiki-page" href="https://osmocom.org/projects/openbsc/wiki/OsmoDevCon2015">OsmoDevCon2015</a>:</p>
<ul>
<li>Date: March 27 through March 30, 2015</li>
<li>Place: IN-Berlin, Lehrter Str. 53, Berlin</li>
</ul>
<p>Like last year, this is an event for developers of the various Osmocom proejects. Reservation and confirmation of reservation is required.</p>
<p>The event is free of charge. The Room is made available by IN-Berlin e.V., an Internet related non-profit organization. Lunch catering will be sponsored (so far by sysmocom GmbH, but if any other sponsors come up, we are happy to share the cost).</p>
<p>So all you have to cover is your own travel + accomodation costs, as well as breakfast and dinner. If you are an active developer and cannot afford travel/accomodation, please let me know and I'll see if we can do something about it.</p>
<p>If you would like to attend, please send a message to <a class="email" href="mailto:laforge@gnumonks.org">laforge@gnumonks.org</a> applying for registration of the event. The registration deadline is February 20, i.e. one week from now.</p>
<p>There is no detailed schedule of talks yet. I will start a separate discussion suggesting / collecting topics in the next couple of days.</p>
<p>More information is (and will be made) available at <a class="wiki-page" href="https://osmocom.org/projects/openbsc/wiki/OsmoDevCon2015">OsmoDevCon2015</a></p>
<p>Further discussion regarding the event should be directed at the <a class="email" href="mailto:osmocom-event-orga@lists.osmocom.org">osmocom-event-orga@lists.osmocom.org</a> mailing list, to avoid cross-posting over the various project-specific lists.</p>
<p>Best regards and happy hacking,</p>
<p>Harald</p> Status Report on Osmocom's 3G Support https://osmocom.org/news/302016-01-27T11:37:00Zlaforge
<p>3G is dead, you may think. From the perspective of large scale operators, that may well be the case, but this is precisely the reason why Open Source support for 3G is becoming increasingly interesting: when the focus for earning money shifts towards LTE infrastructure, the threshold for setting up 3G networks is becoming easier to surpass for everyone else.</p>
<p>We are implementing Iuh support in the Osmocom stack, mostly carried out by employees of sysmocom GmbH<sup><a href="#fn1">1</a></sup>, with highly appreciated (yet undisclosed) external backing.</p>
<p>Iu support in Osmocom will allow using a femto-cell aka hNodeB as BTS, thus enabling UMTS voice (IuCS) and data (IuPS) connectivity using FOSS software from the core network right up to the femto-cell's ethernet jack.</p>
<p>Here is an ASCII art overview of our current aim:<br /><pre>
+------------+ +--------+ +----------+
UE <-->| hNodeB |<--Iuh---->| HNB-GW |<--IuCS-->| OsmoCSCN |
UE <-->| femto cell | ...-->| | ...-->| |
| | | | +----------+
+------------+<--GTP-U | |
\ | | +------+ +------+
| | |<--IuPS-->| SGSN |<--GTP-C-->| GGSN |
| +--------+ ...-->| | GTP-U-->| |
| +------+ / +------+
\_______________________________/
Iuh IuCS/IuPS
NAS +----+----+ +----+----+
Non-Access Stratum | CC | MM | | CC | MM |
- - - - - - - - - - - +----+----+-------+ +----+----+
| RANAP | | H | RANAP |
Access Stratum +---------+ HNBAP | N +---------+ - - SCCP USER SAP
| RUA | | B | SUA | \
+---------+-------+ - +---------+ |
| SCTP | G | SCTP | } SIGTRAN
+-----------------+ W +---------+ |
| IP | | IP | /
+-----------------+ +---------+
</pre></p>
<p>UE (User Endpoint) MS (Mobile Subscriber) mobile device<br />CSCN (Circuit Switched Core Network) == OsmoNITB without BSC<br />(Source: http://git.osmocom.org/osmo-iuh/tree/doc/protocols_around_hnbgw.txt )</p>
<a name="3G-Data-Status"></a>
<h2 >3G Data Status<a href="#3G-Data-Status" class="wiki-anchor">¶</a></h2>
<p>The best news first: in our lab, Daniel has successfully established the first functional UMTS data link!</p>
<p>In other words, the two GTP paths</p>
<p>hNodeB --Iuh--> HNB-GW --IuPS--> SGSN --GTP-C--> GGSN<br />hNodeB --GTP-U--> GGSN<br />are already functional in a basic fashion. To test it, you would need to checkout various branches in various git repositories. These shall soon be merged to the respective master branches, but currently, that would be:</p>
<ul>
<li>libasn1c: master</li>
<li>asn1c: aper-prefix</li>
<li>libosmocore: master</li>
<li>libosmo-netif: sysmocom/sctp</li>
<li>libosmo-sccp: laforge/wip</li>
<li>osmo-iuh: master</li>
<li>openbsc: daniel/gprs-iu</li>
</ul>
<a name="3G-Voice-Status"></a>
<h2 >3G Voice Status<a href="#3G-Voice-Status" class="wiki-anchor">¶</a></h2>
<p>The voice link (IuCS) still needs some work before even the attempt of a location update will make sense. The point here is that previously, OsmoNITB would combine the roles of BSC with the MSC and further core network components. For Iuh, though, the BSC role is actually embedded in the hNodeB, and thus we are aiming to split the BSC part off of OsmoNITB.</p>
<p>The result will be called OsmoCSCN, CSCN meaning Circuit-Switched-Core-Network, which lives in openbsc.git/openbsc/src/osmo-cscn/ (branch sysmocom/cscn).</p>
<p><em>NOTE from the future: OsmoCSCN has since been renamed to OsmoMSC!</em></p>
<p>OsmoCSCN comprises of "only" the MSC and further CN components. It will feature an IuCS interface, as well as, eventually, a proper A-interface towards 2G BSCs, thus obsoleting the OsmoNITB at some point.</p>
<p>Implementing OsmoCSCN is mostly my task, and after sinking some time into training my eye on the fine line between BSC and MSC, I've finally started actual development with the dawn of 2016.</p>
<a name="3G-in-a-Nutshell"></a>
<h2 >3G in a Nutshell<a href="#3G-in-a-Nutshell" class="wiki-anchor">¶</a></h2>
<p>Let me illustrate some details of the Iu interfaces. The following is basically Harald's 3G talk at the 32c3<sup><a href="#fn2">2</a></sup>, but with the sheer abundance of complexity it can't hurt to read it in prose.</p>
<a name="HNB-GW"></a>
<h3 >HNB-GW<a href="#HNB-GW" class="wiki-anchor">¶</a></h3>
<p>The HNB-GW, i.e. the HomeNodeB Gateway, merely reads the CN-DomainIndicator from the RUA layer, which says whether the frame is for voice or data comms (IuCS or IuPS). It then sends the actual RANAP payload either to the OsmoCSCN or the OsmoSGSN. The HNB-GW is implemented in osmo-iuh/src/hnbgw.c, compiling as osmo-hnbgw, and is (mostly?) complete.</p>
<p>An interesting factoid is that for an hNodeB, the GTP-Control handshaking goes via the HNB-GW, while the packet user data actually goes directly to/from the hNodeB and the GGSN.</p>
<a name="HNBAP"></a>
<h3 >HNBAP<a href="#HNBAP" class="wiki-anchor">¶</a></h3>
<p>HNBAP is merely the protocol employed to register an hNodeB with the HomeNodeB Gateway. After HNBAP is done, the hNodeB sends RANAP-over-RUA, which the HNB-GW happily passes on to the proper consumers.</p>
<a name="SIGTRAN"></a>
<h3 >SIGTRAN<a href="#SIGTRAN" class="wiki-anchor">¶</a></h3>
<p>Typically, the IuCS and IuPS interfaces would talk this layering of protocols:<br /><pre>
CC/MM
RANAP
SCCP <--- note
M3UA <--- note
SCTP
IP
</pre></p>
<p>We do have SCCP support in Osmocom, but so far only for "connectionless" messages (like your standard UDP datagrams). Iu now adds the need for establishing and tearing down connections (like TCP).</p>
<p>However, since SUA does the same as SCCP-over-M3UA and is simpler to implement, our HNB-GW talks SUA towards IuCS and IuPS:<br /><pre>
CC/MM
RANAP
SUA <--- note
SCTP
IP
</pre></p>
<p>To support third-party MSC and SGSN components, we would either add SCCP-over-M3UA capability, or simply use an external signalling gateway that supports both M3UA and SUA (should be possible e.g. with osmo_ss7<sup><a href="#fn3">3</a></sup>).</p>
<p>Various SIGTRAN implementations:<br /><pre>
IuCS/IuPS
usual
| simplest
| |
v v
+------+------+------+-----+
| SCCP | SCCP | | |
+------+------+ SCCP | |
| MTP3 | MTP3 | | |
+------+------+------+ SUA |
| MTP2 | | | |
+------+ M2UA | M3UA | |
| M2PA | | | |
+------+------+------+-----+
| SCTP |
+--------------------------+
| IP |
+--------------------------+
</pre></p>
<a name="ASN1-Convolutions"></a>
<h3 >ASN1 Convolutions<a href="#ASN1-Convolutions" class="wiki-anchor">¶</a></h3>
<p>RANAP, RUA and HNBAP, which make up the Iuh interface, are ASN1 encoded. Fair enough, but their ASN1 encoding uses APER, and heavily employs Information Object Classes (which basically means it wraps ASN1 encoded binary data in ASN1 IEs, with several levels of depth). In consequence, the libre asn1c compiler as-is unfortunately is not capable of generating de-/encoders for UMTS. The proprietary ffasn1c is capable of that, and we could publish the ffasn1c generated code without licensing problems, but we'd highly prefer to empower the FOSS community with the ability to modify and fix the ASN1 de-/encoders independently of proprietary software.</p>
<p>The great news is that Eurecom<sup><a href="#fn4">4</a></sup> has worked on supporting both APER and the nested ASN1 structures ("Information Object Classes") in asn1c, and we are able to use their solutions in a FOSS way. With some fixes added, we have both their APER support and their pythonic solution for nested ASN1 available in Osmocom's libasn1c and asn1c git repositories<sup><a href="#fn5">5</a></sup>.</p>
<p>Another problem with the Iuh ASN1 is that various type names are identical across RANAP, RUA and HNBAP, while their encodings differ. This causes type name collisions in the code generated by asn1c, hence we have added prefixing support to our version of asn1c. This simply means that each RANAP-related type name or function begins with "ranap_", and RUA names begin with "rua_", thus avoiding any and all name collisions between those protocols. See osmo-iuh/include/osmocom/ranap/ and ../rua/.</p>
<p>It could be more beautiful, but the bottom line is that we now have fully free/libre support for Iuh ASN1 encodings. Cheers!</p>
<a name="Conclusion"></a>
<h2 >Conclusion<a href="#Conclusion" class="wiki-anchor">¶</a></h2>
<p>Osmocom is on a clear trajectory towards full 3G support, empowering remote communities and small to medium businesses worldwide. Work is ongoing, but the really hard problems have already been solved. Stay tuned!</p>
<p>External References</p>
<p id="fn1" class="footnote"><sup>1</sup> http://sysmocom.de</p>
<p id="fn2" class="footnote"><sup>2</sup> https://media.ccc.de/v/32c3-7412-running_your_own_3g_3_5g_network</p>
<p id="fn3" class="footnote"><sup>3</sup> http://git.osmocom.org/erlang/osmo_ss7</p>
<p id="fn4" class="footnote"><sup>4</sup> http://www.eurecom.fr</p>
<p id="fn5" class="footnote"><sup>5</sup> See http://git.osmocom.org/libasn1c/ and http://git.osmocom.org/asn1c/log/?h=aper-prefix</p> Osmocom Berlin Meeting / 2015-12-09 https://osmocom.org/news/292015-12-08T11:37:00Zlaforge
<p>This is the announcement for the re-incarnation of our bi-weekly OsmocomMeeting/Berlin meeting.</p>
<p>Dec 09, 8pm @ CCC Berlin, Marienstr. 11, 10117 Berlin</p>
<p>There is no formal presentation this time, but</p>
<ul>
<li>there will be SIMtrace equipment in case somebody wants to play with it</li>
<li>there will be a sysmoBTS with OsmoBTS, OsmoPCU, OsmoNITB, OsmoSGSN and OpenGGSN if somebody wants to play with it</li>
<li>The meeting is open to anyone interested in mobile communications. You do not have to be involved with the Osmocom projects in order to attend. Anyone interested in mobile communications protocols is welcome.</li>
</ul>
<p>If you are interested to show up, feel free to do so. The meeting is "free as in free beer", despite no actual free beer being around ;)</p> osmocom.org server outage https://osmocom.org/news/272013-03-29T11:37:00Zlaforge
<p>For about one week from March 20, 2013 on most of the osmocom.org severs and services have been offline due to a hardware failure in the physical machine that was hosting all the virtual machines related to the project.</p>
<p>As I was on extensive business related travel, I couldn't go to the data center and take care of fixing the problem myself. So we had the hard disks sent to my home in Berlin, obtain a machine that has the neccessary SCA-80 connector for the old-fashioned enterprise SCSI hard disks and then start recovery by means of an old backup in the data center + rsync'ing the changes via my slow DSL uplink.</p>
<p>The good news is: Everything is up and running again on different hardware, and there is no data loss as the hard disk was fully intact.</p>
<p>In the coming weeks, we will migrate the various virtual machines over to a new (rented) physical machine, sponsored by <a class="external" href="http://sysmocom.de/">http://sysmocom.de/</a></p>
<p>I'd like to thank</p>
<ul>
<li>zecke for providing emergency recovery for the git server</li>
<li>roh for providing an old Sun v20z to mount + read the SCA drives<br />* <a class="external" href="http://noris.net/">http://noris.net/</a> for mailing the hard disks to Berlin</li>
<li>the community for their patience with the slow recovery process</li>
</ul> Osmocom Berlin User Group / 2013-02-06 https://osmocom.org/news/242013-03-03T11:37:00Zlaforge
<p>This is the announcement for the latest incarnation of our bi-weekly Osmocom Berlin meeting.</p>
<p>Feb 6, 8pm @ CCC Berlin, Marienstr. 11, 10117 Berlin</p>
<p>There is no formal presentation scheduled for this meeting. However, we'll have a progress report + demonstration of current osmo-pcu.</p>
<p>If you are interested to show up, feel free to do so. The meeting is free as in "free beer", despite no actual free beer being around ;)</p> OsmoDevCon 2013-04-04 till 2013-04-07, Berlinhttps://osmocom.org/news/262013-02-26T11:37:00Zlaforge
<p>Dear fellow Osmcoom developers,</p>
<p>it is my pleasure to finally announce the date + venue of OsmoDevCon2013:</p>
<ul>
<li>Date: April 04 through April 07, 2013</li>
<li>Place: IN-Berlin, Lehrter Str. 53, Berlin</li>
</ul>
<p>Like last year, this is an event for developers of the various Osmocom proejects. Reservation and confirmation of reservation is required.</p>
<p>The event is free of charge. The Room is made available by <a href="http://www.in-berlin.de/" class="external">IN-Berlin e.V.</a>, an Internet related non-profit organization. Lunch catering will be sponsored (so far by <a href="http://sysmocom.de/" class="external">sysmocom GmbH</a>, but if any other sponsors come up, we are happy to share the cost).</p>
<p>So all you have to cover is your own travel + accomodation costs, as well as breakfast and dinner. If you are an active developer and cannot afford travel/accomodation, please let me know and I'll see if we can do something about it.</p>
<p>If you would like to attend, please send a message to <a class="email" href="mailto:laforge@gnumonks.org">laforge@gnumonks.org</a> applying for registration of the event. The registration deadline is March 5, i.e. one week from now.</p>
<p>There is no detailed schedule of talks yet. I will start a separate discussion suggesting / collecting topics in the next couple of days.</p>
<p>More information is (and will be made) available at <a class="wiki-page" href="https://osmocom.org/projects/openbsc/wiki/OsmoDevCon2013">OsmoDevCon2013</a></p>
<p>Further discussion regarding the event should be directed at the <a class="email" href="mailto:osmocom-event-orga@lists.osmocom.org">osmocom-event-orga@lists.osmocom.org</a> mailing list, to avoid cross-posting over the various project-specific lists.</p>
<p>Best regards and happy hacking,<br /> Harald</p> Osmocom Berlin User Group / 2013-02-20 https://osmocom.org/news/252013-02-19T11:37:00Zlaforge
<p>This is the announcement for the latest incarnation of our bi-weekly Osmocom Berlin meeting.</p>
<p>Feb 20, 8pm @ CCC Berlin, Marienstr. 11, 10117 Berlin</p>
<p>There is no formal presentation scheduled for this meeting.</p>
<p>If you are interested to show up, feel free to do so. The meeting is free as in "free beer", despite no actual free beer being around ;)</p> osmo-pcu (GPRS Packet Control Unit) v0.1 released https://osmocom.org/news/232013-01-17T11:37:00Zlaforge
<p>After months of work by Ivan Kluchnikov and Andreas Eversberg, the Osmocom GPRS Packet Control Unit (<a class="wiki-page" href="https://osmocom.org/projects/osmopcu/wiki">OsmoPCU</a>) has finally reached a point where it makes sense to release a first version: v0.1</p>
<p>There are still a number of limitations and shortcomings, most of which should be indicated in the wiki at osmo-pcu. However, even without hand-over, timing advance loop, power control loop or dynamic link adaption of the coding scheme, it is already a useful implementation for lab-type setups and small, indoor real-world deployments.</p>
<p>osmo-pcu can be used either with <a class="wiki-page" href="https://osmocom.org/projects/osmobts/wiki">OsmoBTS</a> on the sysmocom sysmoBTS hardware, or with Fairwaves' branch of OpenBTS on hardware like the Ettus USRP family or <a class="wiki-page" href="https://osmocom.org/projects/umtrx/wiki">UmTRX</a>.</p>